GRAFT Weekly Development Status Update November 26, 2018
Time to embrace and structure community code contributions
We have made a tremendous progress over the last year – a stable mainnet, an alpha of the Full Supernode with real-time authorization, and a healthy lineup of components and applications meant to make the ecosystem work end-to-end and provide for adoption.
The other great news is that GRAFT has grown to the point where some significant community contributions are starting to come in – some in form of bug and exploits reports, others in form of algorithm tweaking, others as suggestions for various types of improvements.
While this is fantastic and a sign of a healthy open source project, it does pose a question of how to handle these contributions as, contrary to what it might seem like to a lay man, this is not a plug-and-play situation – these contributions need to be vetted, insured against overlaps, arbitrated in the case of conflicting suggestions, and finally tested extensively. The suggestions do take time to be processed and addressed and for a very busy team of core developers, it can be very time consuming.
Over all, this required quite a bit of thinking and deliberation. As we’re deciding on the model to follow, it’s important to consider different open source development models and their pros and cons.
A little background
Linux kernel development model
Open source projects are usually quite complex as they require coordinating efforts of many different parties, with wide variety of incentives. Because these folks are typically not compensated, they are free to pursue their own interests and beliefs. This typically leads to couple different models for the open source development. One such iconic model is Linux kernel. Despite the fact that Linux doesn’t have a single salaried core team of developers (other than Linus himself), for many years he acted as the project manager, coordinator, and central authority when it came to development decisions.
Now contrast this with Bitcoin’s decentralized development model, where there’s no single maintainer and any disagreement in strategy leads to a split of the project:
These splits not only waste time and energy that could be harnessed, but also create confusion in the market, as evidenced by recent market events.
Settling on a Hybrid Development Model
While we want to end up with a more of a decentralized development model, where the project takes a life of its own without the core devs being in the critical path, we realize that it will take time and efforts to build the community of developers and testers supporting the project. At this point most of external contributions are made by very few active contributors.
To facilitate this process we decided to adopt a hybrid strategy, where the core devs control the direction of the project and carry on the bulk of the development, while the community can organize their submissions into a separate tree that will then get merged into the main tree.
GRAFT Hybrid Community Development Model
To support this approach, someone needs to actively arbitrate the community development. We thought the most appropriate choice would be Jason (@jagerman42) who has graciously agreed to be a maintainer of the community tree. We invite others to step up as well as coordinators/maintainers if they feel like they are up to the task. We’re also open for any suggestions regarding further optimization of the development model.
We will also start publishing more of the design challenges and open issues for the dev community to be informed earlier of the core team’s thinking and to solicit community feedback earlier in the development process.
We’re looking forward to moving towards this model and further evolving the community contribution practices as the project evolves.
