Open Source Business Strategy: About the Open Source Whole Product Concept
James Dixon keeps updating his “Beekeeper model“, analyzing and discussing open source business strategies, now giving a closer view at the importance of the productization process.
Commercial open source, as James states, exists just to deliver software as whole product: an out-of-the-box, easy-to-consume, packaged-and-delivered, risk-free solution.
Italian whole organic product, by fensterbme
Most open source projects do not have anything that equates to productization. The barriers to the adoption of open source exist because open source projects do not have have a productization process. This is the biggest difference between an open source project and a commercial open source company: an open source project does not productize the software, a commercial open source company does.
Open source productization, either in the form of complements enriching the core product or packaged productized services, is a key component to define a proper open source business model. Making the right decision about what to give away and what to keep secret, should come out of an analysis of which are your value propositions and core competencies.
Stephen Walli talking about “ideas” to avoid when thinking of your open source business says:
[..] choose your license wisely: if your entire core competency that enables your core value proposition to your customers is embodied in the software, DON’T publish it in such a way that you give away the company. I have seen a situation in the security world where the software solution was everything. If they had made the software available under the wrong license, they would have essentially given away their future growth.
I totally agree. Funambol business model is a good example: Funambol’s clear-cut distinction between community and enterprise edition enables the company to:
- get carriers happy to pay for what the Funambol Carrier edition has to offer them (core value proposition);
- foster its community, avoiding to upsell it (core competencies).
Funambol keeping secret tools to provision users’ phones, manage devices or send OTA commands doesn’t give away is crown’s jewels. Moreover, it is unlikely if not impossible that carriers would ever create or foster a technological club to cook their own code. Carriers compete, and carrier edition’s features definitely make it a differentiating technology.
Core competencies are not necessarily about code, though. I will leave this for another post, as well as more thoughts on open source value proposition.
online dating victims, 
Roberto Galoppini, 
Tarus Balog 2:28 pm on April 24, 2009 Permalink
I’m a bit lost here. Don’t commercial software companies exist by keeping their code “secret”? What’s open source about a company whose business strategy is based on secret code?
In the examples you give, they are just commercial software companies using a small open source piece as a free API. They use the term “open source” to market themselves, nothing more.
Glyn Moody 4:32 pm on April 24, 2009 Permalink
I do worry this is all getting out of hand, what with “core” and “beekeeper” and who knows what. Do we really need this level of theorising?
p-brane 4:32 pm on April 24, 2009 Permalink
I would like to encourage you to find another term since the set of ordered letters p-r-o-d-u-c-t-i-z-a-t-i-o-n does not spell an actual word. Something is or is not a product. The act of taking raw materials and through some process that results in a product can be called: manufacturing, fabrication, assembly, building, etc. As a product manager, I’ve grown to really loathe the overuse of this non-word.
Roberto Galoppini 6:39 pm on April 24, 2009 Permalink
Hi Taurus, nice to hear back from you. Funambol is a good example of an open core giving away a full-functioning piece of (open source) code, yet offering to a different target proprietary add-ons. I have been talking about how they segment their customer/user base few times, addressing only the top of the ‘pyramid’, have a look at it.
Ciao Glyn, I agree with you that theories and definitions are useful only if we resolve name confusion in favor of customers. Today’s blog post was aimed at starting a conversation around the whole product concept, though.
Hi p-brane, an open source project itself doesn’t make a ‘product’, hence the need to describe the process to create around it all complements needed to make a ‘product’. I will think about use a different term from the one picked by James.
GroundWork Blog » Blog Archive » The Open Source Honey Blender 2:21 am on April 25, 2009 Permalink
[…] to the thoughtful posts of Roberto Galoppini About the Open Source Whole Product Concept, I’ve just finished reading the latest, version 2 of James Dixon’s The Bees and the […]
David Dennis 3:37 am on April 25, 2009 Permalink
Hi Roberto,
I tend to agree with Glyn that would could be rapidly approaching taxonomy overload, if we haven’t reached it already. I recall saying something similar last time we met in San Francisco.
Nonetheless, after reading James’ Bees & Trees, I couldn’t help adding another type of bee-orientied classification.
I called it The Open Source Honey Blender:
http://www.gwos.com/blog/?p=132
Roberto Galoppini 10:23 am on April 25, 2009 Permalink
Hi David,
actually I think your open source honey blender adds some salt to the discussion. So said, I agree that taxonomies are of little help for users and customers, but can help to drive interesting discussion among open source vendors, though.
James putting VCs into the equation, as I originally suggested, brought on the table aspects that do matter for ens users as well: sustainability is key for everybody.
online dating victims 4:46 pm on March 9, 2012 Permalink
I wanted to make sure i commented on this subject.
I am enjoying your dicussion.