Lessons Learned From Building an Open Source Platform
Open Source is a powerful method to build great projects, but it isn’t a magic panacea that will self assemble your platform.
The past year I have learned a lot of lessons on how to develop a decentralized protocol, how to engage core developers and how to offer bounties to encourage development of an open source project.
Below I’ve outlined those lessons so that the whole decentralized community can benefit from them and so that the MSC community specifically knows the direction the Foundation is headed with its bounty system.
1. Empower the developers most heavily involved in the development of the platform.
2. Sponsor developers most involved, to be able to work full time on the clients.
3. Organize developers into teams with daily standup meetings, so that they are in constant communication.
4. Designate a single reference implementation for each use case (eg. designating “MasterCore” as the downloadable client and “OmniWallet” as the web wallet) and focus a single team dedicated to each implementation.
5. Set up specific bounties, narrowly defined, and with short timelines of two weeks or less.
6. Have those most involved in development define the specific bounties and judge their value.
MSC Platform History:
At first, the Foundation started with a very loose approach of offering very generalized bounties for what ever developers came up with when it came to creating wallets, clients and building features listed in the protocol.
Over time it became clear that those contributing the most useful code were those focusing their time and efforts on the MSC platform and fully aware of the context and progress of development. The Foundation began sponsoring full time developers as part of its “Role Based Bounty” program. This program expanded over time from a few developers to its current size of 12 full time developers being sponsored.
At the same time generalized bounties continued to allow independent developers to contribute code and be rewarded at the end of each month, based on rankings from the other developers.
However this process has become tougher over time as the teams grew and developers had less visibility into projects outside of their team and even less insight into independent efforts. Also, without clearly defined bounties, the independent efforts of developers were uncoordinated, fragmented and difficult to integrate into the features of the clients.
Bounties Moving Forward:
1. The Foundation will no longer be sponsoring developers who are only engaged on a part time basis. Engaging team members full time has proven to be much more effective, as this enabled team members to be fully in sync, and drive the pace of feature development forward.
2. Starting September 1st, the Foundation will be phasing out generalized bounties and instead only listing specified, narrowly defined, and short term bounties, which will be judged by the developers most involved in that area of development. These bounties will be posted and shared with the community and serve as the open door, for new developers to prove their skills and the community to provide input on the direction of the MSC platform.
Empower those most engaged and who are committed full time.
Focus efforts on getting a single reference client up and running before rolling out multiple implementations.
Communication and keeping synced on context of development is key.
Define bounties specifically in order to spend funds wisely.