When we think about the quality of our software, we often think about getting the code right. But our ability to deliver and sustain good quality software over time extends beyond the actual code. The creation of today’s software combines modular component reuse together with custom developed code. Dependencies are often external and maintained by many different people. This new level of complexity creates new points of potential failure and risks that are born outside the code base.
Delivering quality software today means not only developing quality new code, but also means choosing quality code that comes from other developers and other development communities. Remember the last time you evaluated and chose a commercial, third party piece of software? You likely did a fair amount of due diligence, ensuring that the company behind the software could provide the support you needed; ensuring that the license allowed you the freedom to use the software as you needed; ensuring that the roadmap for the product was going in a direction that would support your future needs; and more. In today’s world of open source software, all of these same questions need answers. And the answers will determine the fit and the risk that you are adding to your project.
Open source projects come in all sizes and shapes, so it’s important that you go beyond the functional capabilities and look into the community behind the project. Quality means that not only the code is good, but that the code will be maintained with a level of responsiveness that meets your needs. Depending on the maturity of an open source project, the size and activity level of the community will play a key role in the ongoing quality of a component.
The health of a project is often assessed by the number of net-new contributors, representing how many people are interested in joining the community surrounding the project. Combining the number of contributors with their size and frequency of contributions provides good insight into the health of a larger project. Newer projects are often in a high state of evolution, so understanding the pace of development, size of the community participating, and growth rate of the community will all be important. And while all new projects typically start with only one or two people, putting your trust in a project with a team of this size could be risky.
As projects mature, we often see large numbers of people contributing to bug fixes, documentation updates, integration elements, and other adjacent contributions. More mature projects that have been around for a long time and have large user bases often come in two forms: either the project continues to expand and grow into new areas sustaining a large number of contributors; or the project is basically complete and therefore has little ongoing activity. But even though these projects may have less activity, they still require commitment and continuity from a small community.
Free resources like Ohloh.net can help provide insights into open source project communities. The Ohloh chart below is from a large, successful project, showing a steady stream of active developers.
Image may be NSFW.
Clik here to view.
The following “spark-line” chart from Ohloh shows another project with many active developers, demonstrating the strength and commitment from its community.
Image may be NSFW.
Clik here to view.
So the next time you think about using a new piece of open source code, take a minute to check out the community before you make your final selection. It’s no longer enough to solely focus on the code — community needs to become a key element of quality assessment and open source selection.
You can hear more on this topic by viewing my recent webinar with Coverity’s Keri Sprinkle and Jon Jarboe:Driving Quality, Security and Compliance in Third Party Code.
The post Software Quality Goes Beyond the Bits appeared first on Software Testing Blog.
