The word “community” gets thrown around a lot in open source. So what does it mean?
People involved with open source community have differing political, social, economic and ethnic backgrounds. They range from elementary school students to the older adults. They work across timezones, languages, and cultures.
Some developers may work on only a small part of the project codebase, while others know every line from memory. Communities also include people who may not work on the source code directly, such as graphic designers, testers, tech writers and community managers.
When talking about community, it helps to focus in on political and social structure. The project participants you talk to may or may not formally represent the project. Assume, unless otherwise stated, that people represent and speak only for themselves when you interact with them. However, identifying the leaders and the project structure can help you to better interact with all members of the project team.
Community leadership structure
Much of the authority in a project rests with those people who control the community code. At least, it starts there. Actual organization varies widely, but there are some common structures that may help you find your bearings.
Benevolent dictator
Many projects start with a single developer. As time goes on, this person, often called a “Benevolent Dictator” maintains control of most or all commits to the core code, taking patches or branch pushes as they see fit. As more contributors are attracted to the project, the Benevolent Dictator may not do so much dictating, but is often guide for new folks. When there’s conflict, the Benevolent Dictator usually makes the final call.
Many committers, rough consensus
Some projects allow almost anyone to change their codebase. These groups are likely to give commit access to GSoC contributors as part of a project. When deciding which features to work on or what code is committed to the main code repo, decisions may be made by the group or left to a few trusted individuals. When there’s conflict, majority approval may be requested before further action is taken.
Decisions are often made based on who has working code, rather than on a theoretical basis. Groups may not formally document how they make decisions. In this case, a little time spent with the group can help you learn the culture and how to work together. If you end up working with a group like this, your mentor will help you acclimate!
Formal organization
As groups grow in size, some kind of organization becomes necessary. The type of formal organization varies widely across social, cultural and political boundaries. Some ways of organizing include:
- Electing a steering committee by a vote of developers.
- Forming a non-profit organization or foundation.
- Creating a for-profit business.
- Joining an existing non-profit organization.
- Formalizing the existing developer relationships by naming a group of committers the “core” decision makers.
These groups can have documented processes for assuming leadership roles, and may put more effort into non-code activity. Generally speaking, formal organizations have governing documents, and a clearly documented leadership group that changes from time to time.
Community is people
Apart from project leaders, open source projects tend to be full of independent, capable people who like to learn. Long-term collaboration tends to turn strangers into friends. Part of what people enjoy about open source development is that they have the opportunity to choose their colleagues. Developers often participate for fun, relaxation and friendship.
When you’re talking to a software community, realize that you’re really just talking to people, albeit some of the most interesting people who create software. Enjoy the experience and be a good neighbor, and you’ll almost always fit right in.