Implementation standards and open source software
Savio Rodrigues' post on the SourceForge OSS Marketplace made mention of an interesting situation that currently exists in the open source industry. As Savio puts it, with links in tact:
"I wonder if SF Marketplace will allow me to see who is offering support & services for, say, Hibernate in one place (i.e. JBoss, Virtuas, Neward & Associates, etc.). But maybe the project owner would have a say in who can offer support for said project? :-)"
After reading that, I started pondering about the maturing relationship between the stewards of open source products and the non-paying/anonymous user/practitioner. Oftentimes (not always) they take the form of independent consultants and smaller companies, but they nonetheless compose an essential element of an open source ecosystem. For example, they remain instrumental in introducing the benefits of open source software to various business communities who depend on them for local IT support and services.
While larger, more established open source companies like Red Hat have begun to establish programs and services for their ecosystem of channel partners. It is imperative for such companies of all shapes and sizes to recognize that they too, must recognize the value of an extended practitioner network and take the lead in terms of guiding and harmonizing it.
Just as open source offers a tremendous amount of value to non-paying customers, it also enables silent channel partners to attach to the ecosystem while extracting and infusing value. Likewise, open source is not only a resource for high quality, low cost software provided as-is, but also as a key component within packaged solutions which are delivered as custom applications. Regardless if those customized solutions are developed in house or otherwise.
As a result, this inherently flexible population of product use requires the identification of certain unifying points of overlap. Otherwise, what is commonly termed as a community can easily reflect a certain fragment of individuals with a narrow, shared set of use and implementation characteristics. The nature of open source, opens the door to change and adaptation by users, further contributing to the challenges associated with better coalescing a representative user community.
Here are a couple first hand experiences, while not wildly unconventional, that serve as example of the diversity of use cases for open source:
- I participated in a series of planning sessions with a business outsourcing transformation group whose IT department needed to deploy heavily customized versions of the Eclipse IDE for internal use by their team of software developers and architects. The delivery of which was handled without external technical support or services.
- Served as an impartial observer & advisor for a mid-market paper manufacturer through their evaluation and eventual implementation of Compiere.
The aforementioned are but drops in an ocean of mostly undocumented adoption scenarios, where each involved businesses tailoring open source products to meet, often industry specific needs. The associated process involved much more than downloading and running an executable version, but did not entail the purchase of a commercial version or indemnification protection from a vendor. These situations also required a blueprint for the companion endeavor, which clearly delineated the basics of the underlying product and the types of considerations that needed to be made during through extension/modification/customization. This is exactly what needs to be standardized for open source products across the board.
As it currently stands, commercial open source companies are in a position to respond and leverage this reality. By initiating the construction of open implementation standards for their products they can broaden the sense of common ground throughout their product communities without encroaching on independence and stifling innovation. Covered by the implementation standards would be heavily technology-centric areas such as: binary & source code integrity, configuration, authentication & security, logging, etc.
These standards would differ from guides and best practices in that they are to unequivocally outline what should minimally exist within a quality implementation (and potential delivery) of the specified product. Users who put open source products to use under an assortment of circumstances would be encouraged to follow these standards not as a draconian measure but as an aide to their efforts. Plus, they would remain open to contribution from the community as a whole, in order to remain inclusive of general needs and desires.
A counter argument might consist of the suggestion to establish certifications for individual products, but in my opinion such an approach is too resource intensive and narrow in focus. Open implementation standards, on the other hand, can serve as a type of consensus for the employment of open source software products. One which takes into consideration the vast disparities amongst the various classes of use cases, while establishing a shared foundation through an alignment with the needs and goals of the total community.
[..] Alex Fletcher commenting Savio’s post come out with some examples of the diversity of use cases for open source, showing how an open source package can be a key component within customized solutions, regardless if are developed in house or otherwise.[..]
(it was supposed to be a pingback but..it didn't work!)
Posted by: Roberto Galoppini | March 31, 2007 at 08:21 AM