Open source projects are managed in a very different way than proprietary software. You probably already figured that out. But why is that the case? And how is the quality of open source software maintained, given that there’s no central project manager controlling everything?
Different from how company and government projects are managed, open source software projects are managed in an entirely different way. Open source projects have far less formal structure, rules and process. In general, there is no equivalent of a corporation’s board of directors or a government’s cabinet. Yet open source projects are often more successful than their closed alternatives.
New users will never change: they will not search for existing answers, and their questions are always urgent—for them, of course. Sometimes they don’t understand that using open source software means they are responsible for how they use it. They don’t know the difference between a project and a product. That’s why they don’t know the difference between community support, free support, and paid support.
On many forums and Q&A engines, you can add guidelines and other tips and tricks to help newbies write good questions that include the basic information required. If possible, enable features like duplicates and automatic suggestions in order to clear up the queue and information provided. Of course, seasoned community members and project experts can be annoyed with beginners, but don’t forget that everyone was once a beginner, too.
Issues are typically a way to keep track of or report bugs, or to request new features to be added to the code base. Open-source repository hosting services like GitHub, GitLab, and Bitbucket will provide you with an interface for yourself and others to keep track of issues within your repository. When releasing open-source code to the public, you should expect to have issues opened by the community of users. Organizing and prioritizing issues will give you a good road map of upcoming work on your project.
Because any user can file an issue, not all issues will be reporting bugs or be feature requests; you may receive questions via the issue tracker tool, or you may receive requests for smaller enhancements to the user interface, for example. It is best to organize these issues as much as possible and to be communicative to the users who are creating these issues.
Issues should represent concrete tasks that need to be done on the source code, and you will need to prioritize them accordingly. You and your team will have an understanding of the amount of time and energy you or contributors can devote to filed issues, and together you can work collaboratively to make decisions and create an actionable plan. When you know you won’t be able to get to a particular issue within a quick timeframe, you can still comment on the issue to let the user know that you have read the issue and that you’ll get to it when you can, and if you are able to you can provide an expected timeline for when you can review the issue again.
For issues that are feature requests or enhancements, you can ask the person who filed the issue whether they are able to contribute code themselves. You can direct them to the
CONTRIBUTORS.md file and any other relevant documentation.
Since questions often do not represent concrete tasks, commenting on the issue to courteously direct the user to relevant documentation can be a good option to keep your interactions professional and kind. If documentation for this question does not exist, now is a great time to add the relevant documentation, and express your thanks to the user for identifying this oversight. If you are getting a lot of questions via issues, you may consider creating a FAQ section of your documentation, or a wiki or forum for others to participate in question-answering.
Whenever a user reports an issue, try to be as kind and gracious as possible. Issues are indicators that users like your software and want to make it better!
Working to organize issues as best you can keep your project up to date and relevant to its community of users. Remove issues that are outside of the scope of your project or become stale, and prioritize the others so that you are able to make continuous progress.
Most people don’t understand anything about free and open source software, communities, and related topics. Don’t expect that most people will learn on their own. The key is to offer education, education, and more education.
In your materials:
- Clarify your business, your project, your products (e.g., the difference between a project and a product), and teach open source best practices inside and outside the company (yes, “inside” includes your colleagues and managers).
- Write clear communication on your websites (corporate, project, docs, blog, etc.).
- Remove the words “free” and “gratis” from your communications and content, and replace it with “open source” everywhere it is appropriate.
Your target is to help users understand that they are downloading an open source project, not a product. This helps them develop accurate expectations about getting support and being responsible users.
You can improve the efficiency and quality of your project by automating maintenance tasks and testing. Automated maintenance and testing can continuously check the accuracy of your code and provide a more formal process for approving contributor submissions. This helps free up time so you can focus on the most important aspects of your project. The best news is that there are plenty of tools that have already been developed and may fulfill the needs of your project.
- Set up automatic testing for incoming contributions by requiring status checks. Make sure to include information about how testing works for your project in a
- Check out the tools that have been developed to automate maintenance tasks. Several possibilities include automating your releases and code review, or closing issues if an author doesn’t respond when information is requested.
Keep in mind that less is more. Be intentional about the processes and tasks you choose to automate in ways that can optimize efficiency, production, and quality for your project, yourself, and contributors
Open source projects are managed in a decentralized way. This means that there is no single point of control or ownership of a project. This is as opposed to the centralized model used by many proprietary software companies.