Leadership in Open Source Project
Leadership in Open Source Project
Building leadership teams with open source principles in mind can positively affect you and your team's ability to solve problems effectively and efficiently.
Join the DZone community and get the full member experience.Join For Free
The goal of this article is to understand how to build a team or a community based on open source principles and become a leader in this team to effectively solve problems.
“Companies often go through a phase of thinking ‘Oh, well, we’re huge. Why can’t we pound our fist on the table and just make the community do what we want?’ They soon come to realize that tactic won’t work. They come to understand that the only way to gain leadership is to earn the role within the community. And the only way to do that is to gain credibility and make contributions.”
-Guy Martin — Director of Open at Autodesk
Why Aim Leadership in Open Source?
Open Source is Eating the Software World
Smartphones running the Android operating system hold an 87% percent share of the global mobile market and 39% of the global operating systems market in 2019 and this is expected to increase over the forthcoming year. Linux, Android, Wikipedia, Kubernetes all these well-known products are released under a free software license and have public access to source code files.
Open Source Change in Software Development
Agility is the ability to adapt quickly in a constantly changing environment. The speed of change grows from year to year. Markets and work move quickly. To be on track in such conditions companies change strategies should be executed effectively.
According to Gartner research Open Source Change: Making Change Management Work:
- Only 34% of companies succeed in it and only 26% of employees effectively implement change.
- Open Source change strategies drive greater change success at each stage of change, from strategy creation to implementation planning and communication
We are living in a world where responsibilities decentralization and distribution become visible in all spheres. Responsibilities moving from top to bottom of the hierarchy. Engineers have more resources and knowledge than top managers and architects, because of constant and quick changes in technology stacks and programming tools. It gives employees a choice of language, technology stack, and other tools or resources. And choice comes together with a wish. A will is the only biggest power to motivate somebody to do something. This is the fundamental difference between top-down and open-source approaches.
Understand the Leader Role
A common pattern which most Cloud Foundation projects follow is to have a governance.md file in the root repository describing main principles and rules such as project government model, structure, decision process, roles, maintainers add/remove process, and so on. There are three common governance structures associated with open source projects: BDFL(BDFL), Meritocracy and Liberal contribution. Except for the first model which is considered as an antipattern the leader's responsibilities and decision authority in open source worlds are covered by a group of people. For example in OWNERS in Kubernetes, Technical Steering Committee in node.js and PMC(project management committee) in Apache.
The variety of possible roles can be very different and depends on the specific project community. But there are three main roles which can be applied for most of the projects:
- Contributors - is any individual creating or commenting on an issue or pull request.
- Committers - is a subset of contributors who have been given write access to the repository.
- Owners/Maintainers - set direction and priorities for a subproject or special interest group(SIG).
Within this organization "Lead" refers to someone who is a member of SIG, Tech Committee, or Subproject Owners group. There is no one leading any community group. Leads have specific decision-making power over some part of a group and thus additional accountability. Each project responsibility is detailed below.
In comparison with the Enterprise hierarchy where responsibilities between Architect, Business Analyst, and Technical Lead are defined by company authorities in OSS requirements come from users and contributors throw the defined communication channels such as email list, chats, messengers, or issue tracking systems. Community members then vote or agree through discussions to include new requirements into the project's future set. The historical record of their discussions stored there, within the email, chat archive or issue tracker to document why, how, and what should be done in the scope of this feature. Once asserted, there is generally no further effort needed to document such a capability as a requirement. Asserted capabilities then become taken-for-granted requirements that can be labeled or treated as obvious to those familiar with the system's development. The owner's role is to help the community reduce discussions, find the best solution, and define requirements by providing guides, rules, and templates.
Grooming, Prioritizing and Planning
The leader's role is to establish a flow to help other contributors easily take work in process. For example in Kubernetes, all feature requests, issues, and bugs are grouped by labels like kind/, area/ and priority/. According to labels, committers and owners of specific areas or groups take them into further grooming in their communication channels or face-face meetings. Once all issue discussions are clear it can be estimated, planned, and added into either the current or next milestone. For example, this is how backlog grooming takes place in the Kubernetes project. To participate in grooming sessions properly you need to understand business requirements and know how to translate them into software solutions.
Define Team Rules and Coding Standards
Every project and team has rules and standards either explicitly written in documents or shared via day-to-day communication. Discussions regarding coding style could spend a lot of working time as each programmer has preferences. To avoid redundant disputes every major open-source project has its style guide: a set of conventions about how to write code for that project. It is much easier to understand a large codebase when all the code in it is in a consistent style. For example, Google has a list of style guides for almost each programming language. Clearly defined written standards and rules from the begging of the project can save a lot of time and accelerate the development process.
All individuals are allowed to participate, but their influence is based on publicly earned merit – what they contribute to the community. The merit lies with the individual, does not expire, is not influenced by employment status or employer, and is non-transferable (merit earned in one project cannot be applied to another).
Code review is the central part of developing high-quality products. Any committer can review code but at least one owner should indicate positive feedback before moving changes further to the upstream source branch. Code review is a point of interaction between people and mindsets. Besides the main “respect each other” rule, it is also good to remember general code review rules and revise them when required.
Code Quality and Release Management
The release is a set of features or changes marked under the same product version. In open source communities, it is usually steered by a group of dedicated committers. For example sig-release in Kubernetes or PMC in Apache. In the scope of the release group members responsibilities are:
- Release scheduling
- Production Readiness compliance
- Release quality assurance
- Ensure artifacts packaging and publishing by release policy
- Collecting metrics and quality reports related to the release to measure progress over each release
- Release demo. Scheduling and conducting demo meetings to present and collect feedback for the new features and changes
Support is a major cost center for many organizations. Paid support is one of the strategies to commercialize open-source projects. For example, one can subscribe to Red Hat Enterprise Linux and pick a level of support. Providing such a service Red Hat becomes a well-known company acquired by IBM for $34 billion. Project users are the main source of feedback and issues reports. All issues are available for publicity via a dedicated tracking system. In open-source projects, users have the possibility not to wait till the issue to be fixed but to resolve it by themselves and become a contributor. The role of leaders is to provide users with a clear process and communication channel to do this. The key factor is to make issue reporting as much simpler as possible to engage users in reporting.
Everyone can start contributing to the project as a mentee. The project leader's responsibility is to provide a mentoring program on how to do that so the volunteers can start easily. A community member who commits to help a new contributor get started is a mentor. The new person, on the other hand, is a mentee. The idea behind the program is to help mentor and mentee find each other, find sub-projects to contribute, create a plan, track and summarise it properly. The mentoring program is not for teaching to write code but to help make a valuable contribution. This is the example of the mentoring program from the Apache Software Foundation.
Leading and contributing to open source projects connects you to a community of highest professionals where engineering practices and rules are much more mature than in an average IT company. Working in such an environment will keep you on top of the latest engineering practices and make your professional technical skills grow. A leader's goal is to build up the community and develop a shared sense of responsibility.
Opinions expressed by DZone contributors are their own.