Reply-To: Bryce Adelstein Lelbach brycelelbach@gmail.com
For some kinds of software projects to be successful, it is vital that they get developers to adopt the project and build an ecosystem around the project.
One of the best ways to attract developers to a project is to make it open. In an open project, anyone can participate and contribute to the project. Openness attracts developers to projects because it makes them stakeholders. Giving developers influence, input, and insight to a project assures them that the project is something they can adopt and rely on. It also helps the project, because it makes it easy to identify the needs and priorities of the users.
Open projects are often called "open source". But such projects are require more than just open available source code. The governance of the project itself must be done in the open.
Often, there are groups working on an open project who wish to develop closed components which are either never intended to be made open or will only be submitted to the open project after a certain date. An example of the former category would be a company developing proprietary extensions on top of an open project. An example of the latter would be a company developing components for an unreleased hardware product that will be made open after that hardware product has launched.
For a project to truly be open, closed development must be minimized. Closed development excludes those outside of the group doing the closed development. Exclusion is contrary to the very nature of open development; the whole point of an open project is that everyone can participate.
As much development as possible must happen in the open; closed development should be minimized to only what is absolutely necessary. Therefore, the development process must be optimized for open development at the cost of closed development. The closed development will be more costly, but that is a benefit; it helps ensure that it is only used when needed.
Whenever there is both open and closed development occurring on an open project, the open development systems and processes must always be the source of truth. The closed development systems and processes are always subordinate to their open counterparts.
The responsibility of dealing with conflicts and issues between open and closed components falls to the group developing the closed components. They must either deal with the conflicts or issues themselves, or transfer the responsibility to the open component by demonstrating the problem in the open. The burden is always on the closed components. This incentivizes moving as much as possible into the open.
The most upstream branch must always be a public one; let's call it root.
All other repositories and branches are downstream from root and must regularly integrate the latest changes from root into themselves.
Ideally, this is done through an automated mechanism; in the case of conflicts, manual integration is performed.
The burden of integrating changes from open branches into closed branches is on the group maintaining the closed branches.
Closed branches may be maintained in a different version control system than the open branches. If this is done, the developers of the closed branches should mirror and preserve the history of the open branches. This simplifies integration from upstream and future contribution of closed components to the open project.
Project and release planning for open components must happen in the open. If planning for open and closed components must be coordinated, that coordination must happen in the open.
Planning for closed development can happen privately in a different system, but it must take into account the public planning. Closed planning should only be done for things that must be either ephemerally or permanently closed.
Closed planning should be done in the open as much as possible and should seek input from the open community. This makes it more likely that plans will be accepted when and if they are made open.
Review of proposed changes to and plans for the open components must happen in the open. If proposed changes or plans have a negative implication on closed components, the developers of the closed components should demonstrate the issue in the open. Problems in closed components that cannot be explained in the open are not a sufficient cause to reject a change or plan.
Review of proposed changes to and plans for closed components can happen privately in a different system. However, if the closed components are ever made open, they must go through the open review and approval system.
Any issues with an open component must be tracked in the open. This includes issues that only affect closed parts of the project. If there is an issue with an open component that only affects a closed component, the developers of the closed components must find a way to demonstrate and explain the issue openly. Ideally, tests or examples that demonstrate the closed use case should be added to the open components; this transforms a closed use case into an open use case.
Any closed issue tracking systems must be subservient to the open issue tracking system. Ideally, an automated system should import and sync issues from the open issue tracking.
The continuous integration used during review and approval of changes for open components must be open.
A closed continuous integration system may exist to provide additional verification of the open branches or to verify closed branches. Those running closed continuous integration are responsible for any problems that only arise in the closed continuous integration. Failures in the closed continuous integration system are not grounds for rejecting or reverting a change unless the failure can be demonstrated in the open.