Open Source Business models: to be or not to be community-driven
While Seth Grimes was in Rome we took a chance to have a nice chat talking of open source business models, and we happened to discuss about differences between proprietary and open source business models.
How old is your community? by Insane Zamboni
Characterizing Open as Altruistic and Closed as Profit-driven is, agreed, too black-and-white to explain the many businesses that seek to profit from open source. But on reflection, I like my table as-is. Open-source businesses are universally hybrids, whether they seek to profit from their altruism – those companies such as CentricCRM and Pentaho that sell support for software offerings that are completely free, open source – versus those such as SugarCRM and JasperSoft that are altruistic only to the point where they can attract paying customers for the closed parts of their software stacks. Open-source businesses span the table columns. Whether Open or Closed predominates in a given case depends on the particular business model.
Reading Seth’s back thoughts on what characterizes open and closed business models, I got back to the idea that classifying Open Source production models is not a mere academic curiosity. On the contrary it makes a lot of sense, since it affects at large the software life-cycle.
|
Corporate Open Source |
Hybrid Open Source |
|
|
Supplier |
An Open Source firm |
A multi-stakeholder entity |
|
Product development |
Driven by corporate economics |
Driven by product functionality |
|
Developers |
Limited numbers, all employed by the supplier, not reachable from outside the organization. |
Varies from a small to very large group of developers. Often permanently employed by the original author or other firms, volunteers or sponsored. |
|
Users |
Commonly not organised, every user maintains – if any – direct contact with the supplier independently from other users. |
Users participate in virtual communities and discuss among themselves and with the developers about the product, potentially influencing its development. |
The original version (edited) was extracted by the Open Source Maturity Model document
While I can’t agree with Dion Almaer that if a company open sources its software it is a token gesture, I believe he raised some very important issues, describing what he meant for community driven open source – or hybrid production model, in my words.
If you don’t have any committers from outside of your company. You probably aren’t community driven.
If you didn’t spend time cleaning up documentation for the community when you opened it up. You probably aren’t community driven.
If your users haven’t helped with the documentation if it is lacking. You probably aren’t community driven.
If you do not have some kind of forums/lists where people help each other out. You probably aren’t community driven.
If you aren’t willing to put in a lot of effort to build your community to get true benefits. You probably aren’t community driven.
I don’t think an Open Source firm has to fulfill all of these requirements to proudly call itself community-driven, but if they can’t positively answer any of them I doubt they are taking part of a so-called community.
I warmly suggested Carlo Daffara to take into consideration also this aspect when describing open source business models within FLOSSMETRICS.
Is your Open Source Firm different?
Roberto Galoppini, and 1 other are discussing.
Chris Marino 1:18 pm on May 17, 2007 Permalink
Tony Wasserman at CMU West has done some research into this and has developed a framework for organizing the different methodologies.
Dominic Sartorio 2:16 am on May 18, 2007 Permalink
Thanks for raising this excellent topic. At the OSA (Open Solutions Alliance), we have a diverse membership and are often asked what we consider to be “open” business models. So, we track this issue with great interest.
Inevitably, discussion goes down the path of licensing, or how strong each member’s community it. What isn’t discussed enough, IMO, is what best meets customer needs. Ultimately that should determine which business models are best. Unfortunately, there’s no simple answer. Customer requirements can vary greatly, depending on industry, their IT best practices, the type of solution in question, and the skills and know-how required to implement it. Companies that serve different market segments must evolve their business models to best meet the requirements of that segment. Some may be more services-intensive, requiring frequent code customization for example, while others aren’t necessarily best served by purely OSD-compliant management and licensing of source code, but benefit from “open-ness” in other ways. Because open source, especially in the applications space, is still relatively new, we think there is much room for experimentation regarding what business models are best for the most customers. Consequently, we don’t limit our membership based on some preconceived notion of business models we think ought to be the best. Let customers decide that, not us.
However, there is one notion that we don’t compromise. There’s a difference between “old guard” proprietary organizations and more open, collaborative organizations. The former hoard know-how, act unilaterally, and are always trying to “manage” how customers and partners perceive their products and solutions, as if yielding as little real information as possible is the key to business success. The latter instead share know-how, and act collaboratively with their customers and within their industry, and they compete based on their ability to make customers successful. We fundamentally believe that open and collaborative behavior is consistently superior to closed and unilateral behavior. This difference go beyond how the source code is managed, to how the company fundamentally operates; How it engages with its customers and partners, its corporate marketing, and even corporate culture and internal politics. A company’s DNA is either one or the other; these don’t mix.
This is hard to quantify, but you know it when you see it when interacting with the management. There are some typical markers… GPL-licensing is a good sign. So is having public forums for customer feedback. (A closed company would never want the rest of the world to see an unfiltered view of what its customers think about its products.) But there are multiple ways a company can operate and still be “open”.
Your thoughts are welcome. I’m not sure it’s possible to form a comprehensive taxonomy of open business models, but that doesn’t mean we shouldn’t try.
Roberto Galoppini 8:53 pm on May 18, 2007 Permalink
Chris,
I have been a strong advocate for the Open Source Maturity Model, and I thought that the Business Readiness Rating could be considered its evolution.
None of them became a standard yet, before them even the GRAM/GRAS list had not much success indeed.
Apparently consultants did not succeed by these means in producing definitive answers on which open source software is best suited to cover a particular need. Why? Once again one size doesn’t fit all.
Roberto Galoppini 5:48 pm on May 20, 2007 Permalink
Dominic,
I appreciated very much that you came over to comment my post and I am glad you at the Open Solutions Alliance are taking seriously this issue.
While how strong each member’s community is, it is partially due to members’ choices, licensing on the contrary is totally under their control.
I wrote about “false positive” talking about OSA’s decision to accept members not using open source licenses.
You are right saying that there is room for experimentation regarding what business models are best, but pretending to sell open source while selling proprietary software is misleading.
If you don’t compromise (only) on the degree of openness
you should be clear about it, and tell everyone OSA has decided not to talk about open source (while not it is even under the logo, reporting “open source at work”). Then you might consider to make some changes to your website, that says:
This way OSA is contributing to make open source definition uncertain, don’t you agree?
Your opinion is always welcome.
Dominic Sartorio 11:24 pm on May 20, 2007 Permalink
Hi Roberto, Thanks for your thoughtful reply. Yes, we had our own “false start” through sloppy use of the term “open source” when we originally launched last winter. Open Source (capital ‘O’, capital ‘S’) means something very specific, as defined by the OSI, and the OSA intends to cover broader ground, for the reasons I described in my previous post. Our collective experience has been that customer value can be achieved in a variety of ways, and some of them don’t always fit a strict definition.
You found other parts of our website that we overlooked. Thanks for finding this, and we will fix this. We don’t intend to cause further ambiguity around what it means to be “open source”, but rather clarify an issue that we believe hasn’t received enough attention: focus on customer needs. In an effort to avoid confusion, we came up with our own term, “Open Solution Definition”.
Rest assured that our continuing work on this issue will be done in fully open and collaborative ways. Just like open and collaborative development has led to great Open Source products, we believe that open collaboration by the vendor community on various business issues is the best way to achieve customer success.
Many vendors are incapable of this behavior. Some grew during the pre-WWW time when business success depended on unilateral behavior and “knowledge hoarding” than the collaborative behaviors that modern technologies now enable. Take a look at a more recent blog re: the Microsoft patent issue as an example.
DevWebPro » Post Topic » OSCON 2008: Open Source Conference 2:23 pm on July 18, 2008 Permalink
[…] the issues and opportunities presented by community development, in particular the themes of hybrid models. On Tuesday I won’t miss Mark Shuttleworth’s keynote, and I am definitely sorry that I’ll fly […]