Fork and Pull Alternative

How to scale and improve collaboration

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 anupstream 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 master and 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.

Branch Allocation

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.

One remote

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.

Definitive structure

Branching structure is well defined. Solution branches are allocated under the s namespace ( i.e. s/123 or 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.

Joltem didn’t work out, but the code is open sourced here. Feel free to fork and put it to use.