Another blog to keep an eye on
I have had the opportunity to meet Gianugo Rabellino at the 2007 Open Source Think Tank and found him to be quite congenial and intelligent. His blog confirms my impressions of him, as it offers commentary on many issues that I find interesting, especially his frequent and impassioned defense of the BSD and Apache licenses (which is no surprise as Vice President and PMC chair for the Apache XML Project).
OSS Ecosystem Presentation (not by me)
An OSS developer at 55thinking.com has come up with a presentation on open source ecosystems. While I think it is a beautiful presentation, I think it is a good overview of the 'correct' approach one needs to take with respect to getting into open source.
Open Source Ecosystems Research
In doing a scan of open source related news and blogs, I came across Alex Fletcher's blog posting on open source ecosystems. Imagine my surprise, since my dissertation is directly concerned with this very topic (and I've blogged Alex on a similar subject before). I admit it is a fairly involved set of concepts, but it can be boiled down pretty simply. Thus, the paragraphs that follow are a very, very brief summary of the framework and results of my research as it relates to open source ecosystems.
Generically, we can define an ecosystem as it is defined in Ecology: as a set of communities and the surrounding environment forming an interacting system. A community in turn is a set of populations of species living closely enough together for the potential of local interaction, or alternatively, the populations that are found in a defined region. Within previous organizational literature, a community is a bounded set of similar organizational forms (c.f. Ruef).
By contrast, an ecosystem consists of the various populations and communities of these similar species that interact within a given region along with the elements of the environment that affect these interactions. The two terms (ecosystem and community) are a conceptual cluster (Jax 2006) that result in two terms so similar as to be nearly synonymous. Here, we view ecosystems as being more inclusive than communities, reserving the latter for subsets of the ecosystem that exist and interact largely independent of the larger ecosystem.
In software, there are (at least) two communities that matter: the development community that includes those who write the software, testers, and support staff as well as those of the components that are included in the final product, and the user community that includes the end users (OEM/ISV, end users, and consulting partners), not to mention the CEO/CIO/management team of these organizations. The temptation is to combine both sets of people in a single community, but in reality we find that these developers interact with the end users only rarely, especially those for upstream component providers. Pursuant to our previous definition of communities as existing and interacting independently of each other, we find in reality that the developers largely work separately from the efforts of the sales/marketing team on the user side particularly as the organization grows in size.
With that as a background, applying the term 'ecosystem' to open source would include more than downloaders, QA testers, and source code committers. Additionally (especially in the current commercial open source environment), we have to include corporate CIOs, analysts (yourself included, of course), investors/VCs, competitors (e.g. IBM and Oracle), sponsors (e.g. IBM and the Apache Software Foundation), and a wide range of customers from perspectives such as OEMs, ISVs, end users, and more. We continue to define the OSS ecosystem in terms of developers (including the QA testers and committers and others) and users. Forrester Research includes four functions around open source: product development, distribution, services, and marketing. All of these are required by somebody in the ecosystem whether that is a central firm or the members themselves.
The problem is not necessarily in identifying or quantifying these members of the ecosystem at large, but in fully defining their contributions and inducements. In other words, what do they provide and why do they do so? For instance, why does IBM participate in the Geronimo project and what do they provide? How they provide the sponsorship and services they provide is a tactical issue that can be identified from the various analyst and media reports. But the reasons behind the decision are not always so obvious. Would IBM have participated in the Apache project so heavily if the ASF had standardized around the GPL license instead of a BSD derivative? Would they have participated in Geronimo specifically if JBoss had not done so well? Have they been able to appropriate the anticipated benefits of the Gluecode acquisition yet?
Similar questions can be asked for any participant in an open source ecosystem. In the final analysis, it boils down to a question of the health of said ecosystem. What makes one ecosystem more healthy than another? What I have found (so far) in my research is that the health of an open source ecosystem is based on three issues. One, how much productivity (vigor) exists in terms of the capital being invested, produced, transformed, and exchanged. It is important to note that capital includes more than just money, but intellectual/human capital, reputation capital, and more. Two, how organized is the ecosystem. A loosely connected band of developers and users are not as healthy as one in which the communications and exchange pathways among the members of the development and user communities are solid and repeatable. Third, how resilient is the ecosystem. Mere stability implies that an system can remain at a given level of functionality but resilience implies that it can adapt and recover from significant changes in the system.
In a later post (or send me an email at dewynn at uga dot edu for an advance "Cliffs note" summary), I will discuss the concept of a 'mechanism' and how successful (healthy) open source ecosystems have been able to develop and use specific types of mechanisms to improve and maintain their health.
Generically, we can define an ecosystem as it is defined in Ecology: as a set of communities and the surrounding environment forming an interacting system. A community in turn is a set of populations of species living closely enough together for the potential of local interaction, or alternatively, the populations that are found in a defined region. Within previous organizational literature, a community is a bounded set of similar organizational forms (c.f. Ruef).
By contrast, an ecosystem consists of the various populations and communities of these similar species that interact within a given region along with the elements of the environment that affect these interactions. The two terms (ecosystem and community) are a conceptual cluster (Jax 2006) that result in two terms so similar as to be nearly synonymous. Here, we view ecosystems as being more inclusive than communities, reserving the latter for subsets of the ecosystem that exist and interact largely independent of the larger ecosystem.
In software, there are (at least) two communities that matter: the development community that includes those who write the software, testers, and support staff as well as those of the components that are included in the final product, and the user community that includes the end users (OEM/ISV, end users, and consulting partners), not to mention the CEO/CIO/management team of these organizations. The temptation is to combine both sets of people in a single community, but in reality we find that these developers interact with the end users only rarely, especially those for upstream component providers. Pursuant to our previous definition of communities as existing and interacting independently of each other, we find in reality that the developers largely work separately from the efforts of the sales/marketing team on the user side particularly as the organization grows in size.
With that as a background, applying the term 'ecosystem' to open source would include more than downloaders, QA testers, and source code committers. Additionally (especially in the current commercial open source environment), we have to include corporate CIOs, analysts (yourself included, of course), investors/VCs, competitors (e.g. IBM and Oracle), sponsors (e.g. IBM and the Apache Software Foundation), and a wide range of customers from perspectives such as OEMs, ISVs, end users, and more. We continue to define the OSS ecosystem in terms of developers (including the QA testers and committers and others) and users. Forrester Research includes four functions around open source: product development, distribution, services, and marketing. All of these are required by somebody in the ecosystem whether that is a central firm or the members themselves.
The problem is not necessarily in identifying or quantifying these members of the ecosystem at large, but in fully defining their contributions and inducements. In other words, what do they provide and why do they do so? For instance, why does IBM participate in the Geronimo project and what do they provide? How they provide the sponsorship and services they provide is a tactical issue that can be identified from the various analyst and media reports. But the reasons behind the decision are not always so obvious. Would IBM have participated in the Apache project so heavily if the ASF had standardized around the GPL license instead of a BSD derivative? Would they have participated in Geronimo specifically if JBoss had not done so well? Have they been able to appropriate the anticipated benefits of the Gluecode acquisition yet?
Similar questions can be asked for any participant in an open source ecosystem. In the final analysis, it boils down to a question of the health of said ecosystem. What makes one ecosystem more healthy than another? What I have found (so far) in my research is that the health of an open source ecosystem is based on three issues. One, how much productivity (vigor) exists in terms of the capital being invested, produced, transformed, and exchanged. It is important to note that capital includes more than just money, but intellectual/human capital, reputation capital, and more. Two, how organized is the ecosystem. A loosely connected band of developers and users are not as healthy as one in which the communications and exchange pathways among the members of the development and user communities are solid and repeatable. Third, how resilient is the ecosystem. Mere stability implies that an system can remain at a given level of functionality but resilience implies that it can adapt and recover from significant changes in the system.
In a later post (or send me an email at dewynn at uga dot edu for an advance "Cliffs note" summary), I will discuss the concept of a 'mechanism' and how successful (healthy) open source ecosystems have been able to develop and use specific types of mechanisms to improve and maintain their health.
