ShadeWyrm
commented
5 years ago Hi! I'm curious if you feel the focus on Technical Evaluation and Technical Options Analysis should be made a part of the 'Standards'.
I have concerns that a focus on technical aspects would do more to damage when the focus is on enablement. Could you let me know if you feel this level of detail is required for what will be considered 'Mandatory' for Departments or if you'd be in agreement for this material to help establish our Playbook (Guidance) which will appear in the open on GCCollab?
https://wiki.gccollab.ca/index.php?title=GoC_Open_Source_Playbook
KingBain
Some of the folks in my group have been looking at how to Evaluate Open source software and have identified some areas of concern . Its a bit much for me to break apart so I wanted to just upload the doucment. I asked the document author for permission and he gave it.
I hope some of it is useful or can create spin off discussions
Introduction
When evaluating open source software, as with commercial software, there should be two primary considerations: functionality and total cost of ownership. Together the overall value of the software can be evaluated. However the value of open source software may come in a different form than commercial software. The following discussion considers the key issues for evaluating open source software vs. commercial software. It has been assembled from various online blogs and forums.
Considerations
The first consideration is that open source software tends to have narrowly focused functionally. There is an expectation users will integrate and manage multiple products together to create a solution. A large open source solution commonly requires one or more core products and 3rd-party plugins. The work of integration, support, and management tends to fall more on the user than with commercial software. This may not be a concern if in-house expertise is valued as part of the solution.
Second, access to support needs to be considered. The quality of open source updates, documentation, and forums will differ by product from excellent to non-existent. However most open source products do not provide a contractual means by which a specific question can be answered or update obtained in a timely manner. This tends to be a greater issue early in a solution’s lifecycle therefore significant lab testing can help offset concerns in this area. Some companies offer commercial support for open source software however this rarely covers all parts of an integrated solution.
The final major consideration is the benefits of open source software. The most obvious relate to acquisition and deployment. While open source software will have an attached license, they generally allow free acquisition and deployment without restriction. Open source software tends to provide ease of integration through open APIs, data exchange tools, and open storage formats. Also, open source software allows full access to the source code for ease of inspection and modification. For these reasons open source software tends to allow flexibly to scale and change the solution to meet future needs and reduce product lock-in.
Evaluation
When evaluating open source software the availability of information presents a barrier. Unlike commercial software, most open source projects do not have a sales and marketing team creating easy to consume information. This poses a challenge and may require searching the internet for secondary sources, reading technical documentation, and lab testing.
In general, open source functionally should be evaluated in the same manner as other software. Beyond functionality, the key questions are: can the solution be managed, is support available, and do the benefits lead to best value? While these questions apply to commercial software, they have increased relevance for open source and can be harder to answer. The questions below provide a roadmap to answering these larger questions for open source software.