This is the first part of another three part series titled "What Every Open Source Company Needs" which will address three main areas of competence that I think every open source software company should work to strengthen. Analysis of how an open source company measures in these areas can be used by those who are evaluating whether to begin a relationship with such a company; as well as it can be put to work by the open source companies themselves who are looking to grow into strong performers within a target market.
Part I: More than a word, models matter
The first part of this series will focus on the importance of using models to develop and cultivate a vibrant product ecosystem. A model can be defined as the concept of a process which is other wise too complex to define. Models are the bridge between planning and actual execution. The importance of such is becoming quite evident during the next 12-18 months, as it is made quite clear that open sourcing a product is really only the first step towards reaping the full benefits of an open source approach. Having source code and its according binary output for free only provides but so much value over the long term, meaning there is a need to offer more value channels through which an adopter community can derive value. Realistically, the term open source has become equivalent to more than just free and open source code that is distributed under an OSI license. It now serves as an umbrella term for the entire mechanism of open, collaborative product development.
Recently in an attempt to capitalize on the gathering momentum behind the open source software industry, a number of closed source software companies are looking at releasing their products as open source. This has given the global open source user community quite a few notable projects and products that were previously hidden behind a proprietary veil. However, it has also increased the noise level surrounding the industry which has made it significantly harder to determine the value of individual products and solutions. As a result it is becoming difficult to get a clear picture of what is available and how those products meet business/user/technical needs. In addition, with start-up software companies finding it increasingly difficult to reach critical mass and compete as primarily proprietary vendors, more and more are considering adopting the open source distribution model from the start.
Models should be used to structure the very core of an open source effort within the context of providing a self-sustaining value chain. The overall goal being to piece together custom models that drive revenue generation, efficiency throughout the product lifecycle, as well as communication internally and externally. One area that can be modeled is that of the community contribution/collaboration. Despite the fact that some of the most effective open source communities are those that form naturally from the ground-up, defining models can help identify and set the intended parameters for a community. Models also:
- Provide a set of working representations of a community's vision and objectives. For example, if an open source product is being targeted at a specific industry, then the defined models would provide the working definition for entities like release versioning, the granting of user/developer roles, project build processes, etc. as they relate to the needs of the users within that industry.
- Help decompose the underrated, yet complex task of building a successful open source product/community/company. Models are already used to describe business operations...they can also be applied to do the same with open source endeavors.
- Assist the difficult merging of people and processes by producing conceptual components which are useful as high-level relationship as well as technical building blocks.
Open source companies which consistently provide the type of value that drives adoption as well as participation, all realize that the easier it is for the reach of their product ecosystem to grow, the better. A quality, extended ecosystem is one that bridges connections across all types of geographic, market issues as well as some competitive barriers. The successful open source projects are those that cultivate working relationships with the different ISV/SI/OEM's that derive value from an open source value chain. Others, such as partners or sponsors that have a direct connection to the product should also be included within that category. Models can be used to cultivate an optimal approach to managing each of these different relationships. While they don't take the place of solid people management skills, models are capable of serving as the bedrock for promoting the development and application of such skills.
One of the biggest challenges of that the open source distribution model presents is that of integrating the essence of open source software into the context of a for-profit company. In order to fully integrate business/corporate requirements with open, collaborative development approaches & processes, the ease with which these two mesh together is going to go a long way towards determining how capably that specific open source company is going to be able to successfully transform input/output from community members into revenue dollars and cents.
The dual nature of any company which provides a large majority of its product without cost while attempting to espouse the traditional values of open source communities and turn a profit is rather amusing yet still intuitive. In these cases, money can't be made into the sole driving force behind actions, decisions, etc. So it should be of little surprise that being able to provide valued product support as well as consistent practitioner traction is paramount to doing so. Being able to guarantee quality support service helps reduce the risk involved with the selection and use of a product. The number of established support models used by various open source vendors provides notice of the benefits of taking the time to establish models that drive core business functions.
One more model driven area should be that of practitioner participation. In this context a practitioner is meant to define an individual who is actively involved (as a user, tester, developer) within the open source community of question. Models should focus on the (who, what, when, where) of a targeted group of practitioners. How well these individuals take to working hands-on with an open source product is as governed by how easy/transparent the process is made out to be, as it is by the value/quality of the product itself. The models that are put into place should be responsible for exposing this appropriate level of ease and transparency in the name of eliminating as many artificial barriers to contribution as possible.