Open source projects refer to projects without obstacles of adoption and alliance, hence making it possible for anyone to chip in, review, rectify and circulate your project for any purpose. Leadership and governance of these projects can heavily benefit from putting in place conventional principles for decision-making.
1. Comprehending the right administration for your sprouting project
The complexity of contributions in a project increases as the project continues to grow. Cooperation between the makers and the contributing takers becomes more difficult to control, as communication, and trust reduces due to heated disagreements.
Various governance models have been used in thriving open source projects and have been a success. They include:
- Self-governance approach
This model is common in small open source communities. It makes it easier for members to share their thoughts freely, communicate amicably and learn who they can trust. Incorporating strong norms that persist in fairness in teamwork and meeting face to face can help keep things orderly in the project using this model as it promotes harmony among the members.
- Privatizing open source government
This model aims to create a positive social benefit for all members included in the open source project. This is done by giving special benefits to makers, which are not accessible to takers. It aims to commercially benefit all participants while giving credit to the pioneers of the project. The model has worked for big companies like Mozilla, Mongo DB, and Redis which are successful brands.
- Centralizing open source governance
This model is driven by the economies of scale, whereby other companies fund these projects till they capture a new market. The investors mainly aim at making them their monopolies and collecting the gains. Peter Thiel the investor of Facebook is living proof that this method works.
Understanding the right governance model to use among the above for the governance of your growing project is hence crucial.
2. Examples of the common duties utilized in open source projects?
Different projects have varying formal roles depending on the agreement of the members. The commonly used roles include:
- Maintainers
A project maintainer may be one person or a few. They are loosely aware of the whole project, keeping track of the ongoing, and are responsible for inspection, maintenance, and repair of equipment. They are also in charge of building source code for binary package distribution and reviewing the project and making sure that it is merged promptly. They are also in charge of directing the developers and reviewers making sure that their communication runs smoothly.
- Contributor
Anyone can be a contributor, as merely commenting on a project, pulling a request, or simply adding value to the project qualifies one as a contributor. Giving valuable insight and feedback is the role of a contributor in an open source project.
- Commuter
An open source committer is a person who has made major input in the development of the project and therefore deserves a separate distinction. The committee has the mandate to modify the source code of the project’s software that will be used in the final project’s release.
Using leadership roles is a healthy way to promote growth and increased participation in your projects and recognizing people who put extra effort into the project is motivational to the members.
3. Formalization of leadership roles in open source projects
Leadership takes the most important role in the governance of these communal projects. While running a small project, formalizing leadership roles can be done by easily adding their names to the contributor’s page. However, a complex project requires more work. Creating a website and adding a team page or a list of contributors can be one way of formalizing leadership roles. A team with an active contributor committee can volunteer to form maintainer teams or subcommittees where they can address issues like security, and triaging community. Also, one should try holding meet-ups for the leaders to discuss certain issues and have the public listen or ask questions. Engaging the public is a way of increasing contribution to your project.
Documenting the leadership roles and offering guidelines on how one can get a chance to either be a maintainer, contributor or committer should also be on your to-do list. Tools like vossibility have got you covered when it comes to tracking the performance of each member hence making it easier to identify outstanding efforts.
4. Delegation of commit access
While many people argue that committed access should be given to all contributors, I chose to differ from this mentality. A committer is a crucial distinction that should only be given to contributors with exemplary dedication to the project. Committers also have the access to source codes and can modify them affecting the final project’s release. Therefore one should be careful about who to access as they may as well sabotage the whole project.
5. The main governance structures used in open source projects
There are three main governance structures for open source projects. They include
- Benevolent dictator for life (BDFL)-This is a title given to leaders of a small open source project. This structure dictates that the leader (usually the project founder) holds the final verdict over any disputes or arguments in the community. This structure is mainly applicable to small projects only.
- Meritocracy –this structure stresses the point that good ideas can come from anyone or anywhere, it brings to light the notion that the best work rises to the top regardless of the person contributing it. Meritocracy is the most used structure of governance as it motivates the members to work harder on the project as the chances of rising to the top are open and performance-based. Apache foundation is a form of a meritocratic structure.
- Liberal contribution –under this structure, influence is measured by the amount of work you have put into the project. The people with the most work, hold the bargaining power in decision-making. Decisions are made through a consensus rather than a pure vote, where only the major issues are addressed and discussed. Examples of companies that used liberal contribution are Node and rust.
One can choose to use any of the above structures depending on the complexity of your project.
6. Are documents a requirement for launching your project?
There is no stipulated time for writing down your project’s governance, but waiting until the project community is in a good place is a wise choice as then it will be easier to draft the documents. Writing brief and precise guidelines about your expectations of behavior, and how you expect the contributors to carry themselves are docs that you could draft earlier.
If you are taking part in a company’s project, it is wise to have a word with them before the launch to set things straight about how they expect you to act and make decisions after the launch and in the future days of the project. You may also include specific things that the public should expect or not from the company after the launch of the project.
7. The effect of corporate contributors on an open source project
When open source projects become successful, they are used by many people, companies, and organizations, a company may end up endorsing a project as a component of a commercial offering. As the project grows further, professional contributors tend to join in. These contributors are paid, and it may make the unpaid contributors feel inferior. However, there should not be any special treatment given to the paid contributors over the unpaid ones, as both insights are beneficial to the project. Seeking to maintain your project conversations concentrated on the contributions and not the motives that drive the contributors should be your ultimate goal.
8. Are legal entities essential while financing your open source project?
No, you do not need a legal entity to support your open-source project. Creating a commercial business is as simple as just setting up a C CORP or LLC if you are based in the US. If you wish to collect donations, you can create a PayPal account or a stripe account and the money won’t be tax deductible, except for those who qualify for nonprofit.
However, if you qualify for a nonprofit, you can find a fiscal sponsor who will accept donations on your behalf in exchange for a share of the same. Software Foundation, Apache Foundation, Linux Foundation, and open collective are all organizations that offer fiscal sponsorship services for open source projects and can be of help.
