Four metrics for recognize successful Open Source Projects

Being a passionate developer and willing, time to time, search a good Open Source Project to contribute with some code makes me particulary aware about metrics, characteristics or features that define a good or a relevant open source project inside the open source community.

The reason for contributing in a project can span from fixing issues or enhancing code that are you going to use in your business, or just contribute in a information technology domain in which you are interested in; as well, your reason could be improve your software coding skills or be a better software engineer; whatever is your final intent , no matter what, you maybe are interested to know if the project is relevant, well documented or well recognized inside the community.

In my experience, I have found four "metrics" or main characteristics that define a relevant and successful open source project in the open source community . I want to share with you today the four "metrics" that let , in my opinion, an open source project outstanding and relevant in the community.

The Contribution metrics

An important factor that makes an Open Source Project relevant, is the number of developers that are involved and focused on a day by day contributing activity , as well the quality of contribution and the number of companies that contribute to the project with relevant commits or opening issues or , at least, sponsoring the project.  I don’t think that a good project could be defined by number of commits in the codebase, but if you found a project that actively involve a large number of committers with many commits during the months, is a good sign of an active and relevant project in the community. A good example of this metrics, is the number of developers involved in the development of the Linux Kernel ( that is doubled year by year) or in Node.js or Firefox community, just to mention few.

On the other side, a lack of developers can drive the project very fast in trouble,  as the recent news on Open Office project can teach us ( in which many activities are now slowly progressing or blocked for the lack of developers contributing or interested in).

Technical debt reduction metric

Another metric that makes an open source project relevant is how is managed and reduced the technical debt. Defining the technical debt as a measure of readabilty, clarity and compliance of the code with the general accepted rules or best practices for writing code in the community or within an organisation, good open source projects are the projects in which the technical debt is reduced commit after commit. I think that open source projects in which documentation is particulary accurate, the process of code review of contribute or commit is followed by the comments or reviews of the senior members of the project (as well the other developers can comment and improve the quality of the single commit using tools like Gerrit, Gitter, so on ) are the most likely to be relevant: all those factors together are able to driving the project to an “optimum” of code readability and code effectiveness. A good example of this metric is the Redis open source database: a project with a good and "insanely" well documentation and in which the issues are followed by a loop of comments in which the author of the database if often involved.

Activity

An official and active mailing list, with many issues commented or replied, many Reddit or Quora threads with Q&A loops are all good signs of a living and active open source project.  Tools or social sharing code platforms like Github or messaging app for developers like Slack or Gitter teach us how is important today share code and be ready to a fast code review as well to redesign a feature  using a social platform and keep connected with developers that are or in a remote area or far from the office or lab in which the project have the “main”  touch base.

Inclusion principle ( an Open Source Project is an Oligarchy not a Democracy)

Open Source Projects that benefits from a  large and  active community, are the most active in finding , spot and fixing bugs and , as final result, improving the quality of code and the relevance of the project itself in the technology domain.

Taking advantage of a large community and ( often) remote, improve the quality of the code; features and code commits being reviewed by different minds with different perspectives and opinions improve the overall quality of the code : in this sense, an open source project can be considered as a democracy of minds. The main features, milestones  and  hot fixes being decided by the author of the project or senior team members or most engaged commiters, makes an Open Source Project comparable, in the other sense, to an oligarchy, in which the leader ( or leaders) of the project apply and teach the best practices in term of software coding rules, define which tasks are most important to the success of the project and need to be moved forward, which part of the implementation need to be fixed and the hot list of the most critical issues.

Conclusion

The definition of the metrics is a result of my experience joining and working in open source projects and in different companies using open source technogies. If you have questions, critics or you want simply extend the list of the metrics with your suggestions, happy to back to you on the comments.

Disclaimer: The views and opinions expressed in this article are those of the authors and do not necessarily reflect the official policy or position or ideas of my company and customers. Opinions are on my own.