To make a successful open source project just add one part transparency, a dash of neutral governance, and a big dollop of listening to user feedback. This is the recipe we’re trying to follow with the Cloud Native Buildpacks project, and, in the spirit of the first ingredient, we’d love to share a status update that will also explain where the project is headed.
Cloud Native Buildpacks, an effort with contributions from both Salesforce Heroku and Pivotal, aims to create a developer-friendly standard for turning source code into Docker images without the need for Dockerfiles. The project is based on Heroku’s original buildpack concept, but embraces modern container standards, such as the OCI image format.
In April, Cloud Native Buildpacks released its first beta. This was a big milestone for the project because it was the first time we signaled that we’re ready for people to try buildpacks. A developer can install the pack CLI, choose a buildpack, and run it to create an image that will work on any Docker-compatible runtime. Now we need feedback from those developers to guide the future of the project.
Looking Into the Crystal Ball
With the first beta behind us, we’re now focused on getting Cloud Native Buildpacks ready for production. This will require, at a minimum, the following:
- Stabilize the v3 specification
- Release a 1.0 version of the Lifecycle (a reference implementation of the v3 spec)
- Release a 1.0 version of the pack CLI
Some of this work involves writing code and squashing bugs, but another part of it requires strong community feedback. In order to make sure we’ve designed a technology that is useful to more than just the people who created it, we need to make sure we listen to our beta users and the community.
To ensure this happens, we want our decision making process to be as transparent as possible. We have public meeting notes, communicate via Slack, and encourage the community to join in our conversations.
We’ve also started a Request For Comments (RFC) process to increase the visibility of the decisions we’re making and help create a record of how we make those decisions. Any large user-facing change is required to go through the RFC process, whether you’re part of the team or not.
An Open Cauldron
A Request for Comments (RFC) process is used to socialize a new idea, gain peer-review and feedback from the community, and ultimately produce a consensus among the stakeholders of the project. RFCs have their origin in the early days of the internet, but many modern projects have adapted the concept to suit the needs of a distributed team working on open source code.
In modeling the Buildpacks RFC format, we looked closely at other projects that already have an established process. In particular, the Rust RFC process inspired much of our design. You can read more about the specifics of our process in the Meta RFC (an RFC that defines the RFC process).
Not all changes require an RFC, though. Bug fixes, documentation improvements, and small non-user-facing changes can all be implemented and reviewed with the normal Github Pull Request process. Changes that are substantial or affect the end-user will require an RFC.
The beauty of the RFC process is that it’s open to anyone. You can read any RFC and its associated comments to understand why the project made a particular decision. You can even author an RFC of your own if you think the project should change in some way — you don’t need any special permission. We hope this will lead to the best design and implementation for Buildpacks.
Conjuring the Next Release
Before we graduate to General Availability (GA) and a production-ready Cloud Native Buildpack platform, we have a few more beta releases ahead of us. In the next release, 0.3.0, you can expect the following improvements, among other changes:
- Better support for pack CLI on Windows
- New integration with Tekton (formerly Knative Builds)
- Improvements to how we publish releases to Github and Homebrew
We’ve also been working on breaking changes to the specification, which you can follow through our RFC process. These need to be finalized and implemented before we can move to GA.
If you’d like to get started with Buildpacks, follow the guide in our documentation. If you find areas that you think need changing, or if you think we could be doing something better please reach out to us on Slack or the mailing list.
If you really want to engage us, try authoring an RFC for your idea. We think you’ll find the process highly transparent and the only magic you’ll see is how easy it is to get involved. You don’t even need a wand.
