Enterprise Open Source Journal’s Sept/Oct 2006 issue has an article on Spotting Low Quality Open Source Code. Their top ten list includes no-no’s such as poor commenting, inconsistent naming conventions, bad code style (poor indentation), missing error checks etc. Now I’ve read a lot of source code and many of the guidelines listed in the article can be generalized to Spotting Low Quality Software Code – not just open source. But it is super critical for open source for a couple of reasons:1) If software is truly ‘open’ to lots of developers, then the code must be maintainable by them. This is really feasible only if the code is readable, simple, adheres to standard conventions, etc.

2) Part of the lure of using open source in the enterprise is the option of an inhouse development team to read, understand and possibly modify or extend the open source code. Again, this is only feasible if the project’s code is of good quality.

3) There are many many many open source projects out there and so it’s critical for the project to achieve a critical mass of usage in production environments in order for it to survive. This implies that the project is needed and is useful by a large number of development teams and hopefully enterprises. General software systems typically need clean designs and high quality code so that they can be applied and extended for multiple needs.

4) Poor software code quality and buggy software usually go hand in hand. If the code is buggy, it will never sustain a critical mass of users.

5) What’s harder; building an application that utilizes an open source system or upgrading the application with a new version of the open source system? Upgrades can be very complex especially if the new version of open source software is not backwards compatible with previous versions in significant ways, or, when upgrades also require upgrading many dependent systems. So with that in mind, if the software code quality of the open source system is poor, how clean or easy will it be to install upgrades?