Collaboration depends on a compromise between access and control. As a maintainer gives up access, control is lost. With lost control a project may lose conceptual integrity. Tuning access is the foundation of any collaboration.
Our goal is to determine a scalable open source access model. It should allow contributors to easily submit contribution, without prior approval. Scale well beyond ten contributors. As contributors come and go, transience should not produce overhead. Most importantly, communication should be fast and simple.
Fork & Pull
Popularized by GitHub, the most popular access model is the fork and pull. Each contributor not granted read access maintains a copy of the codebase called a "fork". Work progresses independently on forks. Once completed, a "pull" request is submitted to the maintainers of the codebase to merge in the changes. A technically simple solution that enables mass collaboration. Naturally it has spread quickly despite shortcomings that convolute the collaboration process.
Managing forks and remotes
The most tangible source of friction is the management of remotes and forks. To a setup a contributor must create a fork, clone it, and then add an upstream remote representing the repository forked. Afterwards they must periodically update their clone and fork with changes from upstream. Each contributor represents a remote that must be added and maintained. Fetching changes fires a separate request for each remote. Trivial for small projects, but it fails to scale as the number of contributors grows.
Absence of structure
Branches represent threads that follow a progression. On independent forks, branching structure is defined by the owner of the fork. Context is lost without a consistent naming structure. A multitude of forks erodes meaning even from conventional branches such as a
develop. Context must be gathered either from commits or by waiting for a pull request.
Communication via pull requests
Communication depends on awareness. Specifically, awareness of the code's state and direction. When this is represented by a hundreds or even thousands of independent forks it becomes incomprehensible. Sporadic pull requests become the main mode of communication. Combined with a lack of shared branches, communication can become frustrating and slow to a crawl. Code is the preferred communication medium.
Working on Joltem we needed an access model capable of housing a dynamic workforce open to contributors. To ease and scale collaboration we chose against the fork and pull model, devised our own scheme, and build a custom git server.
Our model depends on branch allocation. Replacing forks with branches, we enable one repository to serve all contributors. Trusted individuals can obtain complete push access. Other contributors can allocate branches through our task management system. Branch allocation does not require prior approval. It allows the contributor to push changes to the branch.
The obvious advantage is the single remote. Without setup and maintains of a fork, contributing is simplified. Each contributor no longer represents a separate remote, removing the overhead of maintaing them as contributors come and go. Branch tracking is simplified, making it easier to keep branches up to date. All changes are fetched from a single remote, making it fast and simple.
Branching structure is well defined. Solution branches are allocated under the
s namespace ( i.e.
s/89). While maintainers of the project decide the rest of the structure. By assigning meaning to branch names they develop and enforce a branching convention throughout the whole project. Convention saves time for everyone involved.
Communication via code
By unifying the codebase, communication is accelerated. The state and direction of the codebase is a
git fetch away. The access model provides shared branches between maintainers and contributors, enabling communication directly through code. Small corrections can be made to guide contributors away from compounding on small mistakes.