The pros of OSS are plentiful, but the cons are just as numerous. With often a myriad of competing OSS projects, many not professionally supported, little certainty around future releases, rapid updates requiring constant upkeep and buggy early versions, how can one justifiably take the risk? How do we mitigate these cons and filter the wheat from the chaff?
The following assessment criteria should start the evaluation of any open source product/platform:
- Investigate the licensing/legal situation of the software.
- Evaluate whether the software is standards compliant.
- Contact references to confirm product viability.
- Find products with a supporting or stable developer.
- Find products that use an open/industry standard implementation language.
- Reference third-party reviews of the software.
- Reference books published about the software (the more the better)
- Reference industry analysts, such as Gartner, Forrester or IDC.
- Project extensions are available.
- The project has reached a 1 year maturity mark.
- Security patches, bug fixes, and new features/enhancements are delivered separately.
- The core development team has rigid criteria for participation.
- The software has reasonable automated unit and functional tests with code coverage in the 30-80% range.
- The software easily integrates with external services
- The component’s bug database is kept up-to-date with revision numbers for each product enhancement.
- The solution has been ported across multiple platforms (Linux, Windows, Solaris, and Mac).
- The community is organized into groups, each responsible for separate tasks (the maintainer, the documentation group, the development group, the evangelism group).
- The project’s license is acknowledged by the Open Source Initiative (http://opensource.org).
- Large-scale adoption, including both public and well-known large-scale organizational deployments
- Separation of documentation: User documentation, Installation documentation, Admin documentation, and Development documentation
And remember to always weigh target usage of the application (mission-critical, departmental or beta) against the OSS product's readiness.
Many of these points were reiterated by our recent discovery of http://www.openbrr.org. Now that's an example of an open source project that lost it's legs, but what was was left behind was some great info. Thanks to that community!
Please let me know some other criteria we should be considering in the comments below. I'll consolidate feedback and send it on to openbrr.org.
-J
Posts
2 comments:
Good post, J.
I've always tried to use a potential new open source package in non-mission-critical application (or a least a "pet project") before unleashing it in a higher profile production application. Giving an open source project some real world work to do before putting into a more critical project has always given me piece of mind.
Once you decide to move forward with a given open source project, it's important to design your project in a way as to not tie the project too tightly with the given new piece of software. Think about "what would I do if this project died" and design your system so it is possible to replace the given project with something else (by designing your application with clean contracts via interfaces for example).
Thanks Rob, those are some great points and key considerations!
Post a Comment