By nature, software developers – and especially open source software developers – tend to value their independence. And like all of us, they each have opinions about how things should be done. So dealing with disagreements can be all part of the fun when it comes to managing community projects.
Carefully designing a healthy and intelligent organizational structure can sometimes keep a lid on the bubbling chaos. Clear rules and policies help to establish unambiguous expectations for how the project operates and how contributions are managed. Intelligent rules can help to define the project’s governance structure, including how decisions are made, who has decision-making authority, and how conflicts are resolved.
Wherever possible, open source project managers should seek to create a friendly and accommodating environment for their volunteers. One unfortunate example that illustrates this point involves a recent decision made by a major player in the open source world. The organization changed the open source license governing code contributions to an important project, and also introduced a new Contributor License Agreement (CLA). Some of the most important contributors were deeply upset by the move and cut ties with the parent organization, causing some harm to the overall project. I don’t have an opinion over who was right here and whether the dispute could have been prevented, but I do use that particular software nearly every day, so I care deeply about the project.
A large open source project is a community effort. This won’t be the product of just a single individual and, in most cases, there won’t be a company with all its resources to fill any holes. Instead, the responsibility for making sure things get done will be distributed across the entire group. But that’ll require some serious collaboration. The first thing is to be aware of the various roles you’ll need to fill:
Project leads are typically appointed or elected by the community to lead a particular project or set of projects. They’re responsible for guiding the project’s direction and ensuring that it stays on track. They work closely with contributors to ensure that the project meets its goals and objectives. The project lead is the one who is ultimately responsible for just about everything, including tasks like planning and roadmapping, community building, coding, but tracking, and code review.
Benevolent dictators are typically the founders or original creators of an open source project. They’re responsible for making the final decisions about the project’s direction and ensuring that it stays true to its original vision.
Developers are responsible for writing, testing, and maintaining the code. They may work on specific features or modules, fix bugs, and provide code reviews.
Release managers are responsible for coordinating the release of a software product or service. They manage the release process, communicate with stakeholders, manage risks and issues, and ensure that the product meets the required quality standards.
Designers are responsible for creating the user interface and user experience of the project. They may work on the project’s branding, design assets, and visual design elements.
Testers…well, testers test the code to ensure that it is free of bugs and works as intended. They may write test cases, perform manual or automated testing, and report any issues to the development team.
Technical writers create and maintain documentation for the project. This can include user guides, developer documentation, and other resources that help users and contributors understand how to use the project.
Community managers build and manage the community around the project. This can include responding to questions and feedback from users, organizing events and meetups, and facilitating communication between contributors.
Translators are responsible for translating the project resources into different languages. This can include the user interface and documentation, which in technical projects normally start out in English.
Finally, your users – and particularly those who engage with your product with particular enthusiasm – will also play important roles. Besides potentially contributing useful ideas for new features, they’re the ones who encounter bugs in your release, and you’ll want to make it as easy as possible for them to report them.
In addition, some users may decide to fork (or copy) your project and use the code to build something new and different. You might (or might not) appreciate the competition, but that’s how open source works.
Like any large and complex endeavor, open source projects require serious planning, good communication, and a cooperative spirit. One excellent place to begin your planning is with the LPI Open Source Essentials certificate curriculum. Having created a book and course covering the cert, I can tell you that the content you’ll need to pass the exam is nicely aligned with exactly the skills you’ll need to succeed with your open source project.
Source: lpi.org
Posts
