The Problem with Commercial Open Source Software

So you are the CxO of an Open Source Company?  What is your game plan?  How can you make this company be successful under the open source paradigm?

What makes Open Source tick? Is it really the free software? Is it community? I have been at conferences and in discussions when this question has been thrown around. Inevitably someone says “Software development just is software development. It’s community that makes open source different.” Opponents of this view quickly point out that Microsoft, seen as a major cold shoulder in the open source community has a large development community called MSDN (Microsoft Developers Network). In fact MSDN is the largest, most active developer community there is.

People who point to community as the value of open source are on to something. But it is not really the presence of community that is different; it is the mentality of the community. There is something distinctly unique about open source community vs. MSDN.  Successful open source communities have something that doesn’t exist in the MSDN. It’s what some call “The inventor’s spirit”.  Microsoft has a large community to support engineering based on existing Microsoft engineering. Design and practices are essentially handed down from Microsoft on high. Articles explain and discuss Microsoft technology and strategy but there is little room to influence direction (to invent) from the community at large. If you want to change the direction of Microsoft or Oracle, get out your wallet and hope it is got more girth then their other customers.

Open source gives developers the chance to give their time and effort to a product. The amount of latitude given to invent on the product scales from a forked modification / additions of existing software to full design and vision voice. In most open source products, developers attain the right to contribute as inventers with higher levels of influence by demonstrating a level of commitment and insight. In many examples of well known open source products, the emphasis is on engineering.

The commercial part of commercial open source is always in danger of standing in the way of this model. After all product vision is always tied to some revenue component. For example “we will focus on this feature or drive the product in this direction because there is more profit to be made in that direction.” COSC (Commercial Open Source Companies) must be careful in balancing what their clients need versus what their community needs.

If COSC is not thinking about its community it is not Open Source. It is a ploy ridding the open source bubble / wave. If a COSC is not making the community its priority then it may be open source but it’s a failing model.

A community of inventors is the only successful model there is in the open source world. COSC would do well to understand this and modify their practices to leverage this working model. The benefit of being part of the OSS community is that you are looking to spread your visionary, engineering, documentation, support and quality control responsibility and risk around. Vision, engineering, documentation, support, and quality control are all in their own right, hard work. The only thing that is truly a match against the barrier of hard work is something we might call passion. Passion is not something you can bottle, it is no commodity. However, there is one demographic that seems to have more passion then any other: inventors.

Inventors will watch the sun rise and fall several times in one sitting while working to make their invention come to life. Every manager wishes their employees had that kind of dedication to their work but it is rare. You might find it at JPL, Langley or Bell Labs. Exactly, these are all examples of inventor havens. I know of another example of an organization where the individuals work a 16 hour day then come home and willingly work another 8: The Apache Foundation.

COSC will only reap mediocre benefits of open source unless they are able to create a community of inventors.

To create such a community of inventors:

• Be "free as in beer." The open source model that works is services. There is no good hybrid approach to this. Anything less then free (as in "free beer") is seen as Shareware, crippleware, and the like. Remember: Perception is reality. The open source community is unforgiving when it comes to the perception of a product in this space.

My friends and I have a saying that goes like this: “The ‘C’ in ‘CIO’ is for ‘Chicken’. Anyone who has money to give in the first place (A real business); will give it to you for support. Don’t play games with them and force them to do what they will already do. CIOs need to support what the put in place.  Don't worry, its a given in 9 out of 10 cases.

• Let go of the control on product vision. Take IBM and Eclipse as the primary example. Let the community drive the vision for the product. Maintain a strong presence in the community so that the company’s vision is well represented. IBM is one of OSS's biggest contributors, but they definitely assert the IBM position and direction.  They are making open source work for them.

• Focus on revenue without focusing on revenue. COSC is a new model. Think laterally; it is not enough to think outside the box, burn the box down.  OK so you made the jump to the OSS business model.  It's not traditional - stop trying to make it traditional.

• Play well with other open source products. Spring framework is demonstrating mastery in this space. Spring is a framework that seems to bring together all kinds of other frameworks. This model is not to be ignored! Make sure you can plug your product in to other open source products. Make sure you can plug other open source products in to yours.

• Support your community. The community is your number one customer, ALWAYS. There is no bigger, more valuable customer.

• Breed experts on your software. The more experts there are, the more traction you will have, the less support you will need to maintain. If every committer on your product works for you, you are doing it wrong.

• Anything that is not your core problem domain: give away. There is another OSS community working in that space. Contribute there. Don’t be an island of engineering. It is bad form. Give your engineering wider exposure by giving it to other products.

• A large community is the goal. Large communities are hard to build. Large projects are hard to build communities around.

Large projects are a folly. When a project has a large scope it usually indicates that it should be several small projects. This is a concept familiar to software engineers. Some of those smaller projects have nothing to do with the problem domain of the overarching project; give them away.

Build small communities around small projects. The larger community will emerge as a few members of each small community cross over.

Large products should almost be nothing but open source configuration. Pulling together small products in interesting ways.

• Attract Inventors. Make sure they are given the latitude and longitude to invent.

So you are the CxO of an Open Source Company?  What is your game plan?  How can you make this company be successful under the open source paradigm?

What makes Open Source tick? Is it really the free software? Is it community? I have been at conferences and in discussions when this question has been thrown around. Inevitably someone says “Software development just is software development. It’s community that makes open source different.” Opponents of this view quickly point out that Microsoft, seen as a major cold shoulder in the open source community has a large development community called MSDN (Microsoft Developers Network). In fact MSDN is the largest, most active developer community there is.

People who point to community as the value of open source are on to something. But it is not really the presence of community that is different; it is the mentality of the community. There is something distinctly unique about open source community vs. MSDN.  Successful open source communities have something that doesn’t exist in the MSDN. It’s what some call “The inventor’s spirit”.  Microsoft has a large community to support engineering based on existing Microsoft engineering. Design and practices are essentially handed down from Microsoft on high. Articles explain and discuss Microsoft technology and strategy but there is little room to influence direction (to invent) from the community at large. If you want to change the direction of Microsoft or Oracle, get out your wallet and hope it is got more girth then their other customers.

Open source gives developers the chance to give their time and effort to a product. The amount of latitude given to invent on the product scales from a forked modification / additions of existing software to full design and vision voice. In most open source products, developers attain the right to contribute as inventers with higher levels of influence by demonstrating a level of commitment and insight. In many examples of well known open source products, the emphasis is on engineering.

The commercial part of commercial open source is always in danger of standing in the way of this model. After all product vision is always tied to some revenue component. For example “we will focus on this feature or drive the product in this direction because there is more profit to be made in that direction.” COSC (Commercial Open Source Companies) must be careful in balancing what their clients need versus what their community needs.

If COSC is not thinking about its community it is not Open Source. It is a ploy ridding the open source bubble / wave. If a COSC is not making the community its priority then it may be open source but it’s a failing model.

A community of inventors is the only successful model there is in the open source world. COSC would do well to understand this and modify their practices to leverage this working model. The benefit of being part of the OSS community is that you are looking to spread your visionary, engineering, documentation, support and quality control responsibility and risk around. Vision, engineering, documentation, support, and quality control are all in their own right, hard work. The only thing that is truly a match against the barrier of hard work is something we might call passion. Passion is not something you can bottle, it is no commodity. However, there is one demographic that seems to have more passion then any other: inventors.

Inventors will watch the sun rise and fall several times in one sitting while working to make their invention come to life. Every manager wishes their employees had that kind of dedication to their work but it is rare. You might find it at JPL, Langley or Bell Labs. Exactly, these are all examples of inventor havens. I know of another example of an organization where the individuals work a 16 hour day then come home and willingly work another 8: The Apache Foundation.

COSC will only reap mediocre benefits of open source unless they are able to create a community of inventors.

To create such a community of inventors:

• Be "free as in beer." The open source model that works is services. There is no good hybrid approach to this. Anything less then free (as in "free beer") is seen as Shareware, crippleware, and the like. Remember: Perception is reality. The open source community is unforgiving when it comes to the perception of a product in this space.

My friends and I have a saying that goes like this: “The ‘C’ in ‘CIO’ is for ‘Chicken’. Anyone who has money to give in the first place (A real business); will give it to you for support. Don’t play games with them and force them to do what they will already do. CIOs need to support what the put in place.  Don't worry, its a given in 9 out of 10 cases.

• Let go of the control on product vision. Take IBM and Eclipse as the primary example. Let the community drive the vision for the product. Maintain a strong presence in the community so that the company’s vision is well represented. IBM is one of OSS's biggest contributors, but they definitely assert the IBM position and direction.  They are making open source work for them.

• Focus on revenue without focusing on revenue. COSC is a new model. Think laterally; it is not enough to think outside the box, burn the box down.  OK so you made the jump to the OSS business model.  It's not traditional - stop trying to make it traditional.

• Play well with other open source products. Spring framework is demonstrating mastery in this space. Spring is a framework that seems to bring together all kinds of other frameworks. This model is not to be ignored! Make sure you can plug your product in to other open source products. Make sure you can plug other open source products in to yours.

• Support your community. The community is your number one customer, ALWAYS. There is no bigger, more valuable customer.

• Breed experts on your software. The more experts there are, the more traction you will have, the less support you will need to maintain. If every committer on your product works for you, you are doing it wrong.

• Anything that is not your core problem domain: give away. There is another OSS community working in that space. Contribute there. Don’t be an island of engineering. It is bad form. Give your engineering wider exposure by giving it to other products.

• A large community is the goal. Large communities are hard to build. Large projects are hard to build communities around.

Large projects are a folly. When a project has a large scope it usually indicates that it should be several small projects. This is a concept familiar to software engineers. Some of those smaller projects have nothing to do with the problem domain of the overarching project; give them away.

Build small communities around small projects. The larger community will emerge as a few members of each small community cross over.

Large products should almost be nothing but open source configuration. Pulling together small products in interesting ways.

• Attract Inventors. Make sure they are given the latitude and longitude to invent.

Comments

[Paul Beer]

You are wrong to say passion cannot be bottled: it is called beer.

[Nicholas Goodman]

Tried to do comments on your site, but the formatting wouldn't stick...

I've linked along to you:
http://www.bayontechnologies.com/bt/blog/archives/2006/01/great_post_on_c.php

[JosephDP]

I disagree with your definition of the community for an open source project as being only developers. In general, the number of developers who actually contribute new code to a project is, perhaps, 5 to 10 individuals. The community also comprises those who are willing to test the product, and contribute bug fixes. The largest part of the community are the users, some of whom might move into the role of testers or bug fixers, many of whom report bugs or contribute use cases, but never look at the CVS or subversion, and never submit a line of code.

Related to this discussion, in addition to Nick's comments, are a post by Matt Asay and my response.

Mudblood Open Source
http://asay.blogspot.com/2006/01/mudblood-open-source.html

and

Open Source Communities Mudblood or Pureblood

http://press.teleinteractive.net/oss/2006/01/31/open_source_communities_mudblood_or_pure

Also, I would say that the difference between MSDN or similar community for closed-source products and an open source community is two-fold.

1. The community surrounding a closed-source product more closely resembles your definition of community - it is to support inventors, but only invention ON TOP OF the core product(s). The closed-source product company doesn't take advantage of the "long tail" affect as applied to development, to improve the core product(s). This is one strength of open source vs. closed source.

2. There is no end-user interaction within a closed-source developer community. In an open source project community, the end-user makes up the largest segment, and often provides the strongest feedback. This is the second strength lent to an open source project by its community, and why successful open source projects are capturing market share.

Other than that disagreement, I agree with Nick - great post.

[russ danner]

Thanks I appreciate all the comments! Nick I have a number of things I want to respond to on your post but it's going to have to wait.

To respond to Joseph,
I think we are missing each other a little bit. I never intended to imply that inventors where developers only. In fact I mean exactly the opposite. I have a very good friend, Arthur who is a Program Manager. He may be the #1 guy I wish would enter in to open source. He is far from a coder (to my knowledge.) But he is an inventors inventor!

You said:
1. The community surrounding a closed-source product more closely resembles your definition of community - it is to support inventors, but only invention ON TOP OF the core product's). The closed-source product company doesn't take advantage of the "long tail" affect as applied to development, to improve the core products). This is one strength of open source vs. closed source.

I agree that closed-source companies are missing out. That is my central point. Don't encourage your community to develop on top of your engineering. Make the community your major driver. I even went as far as to say if all of your committers and thinkers are employees, I think you have it wrong.

You said:
2. There is no end-user interaction within a closed-source developer community. In an open source project community, the end-user makes up the largest segment, and often provides the strongest feedback. This is the second strength lent to an open source project by its community, and why successful open source projects are capturing market share.

Yes! exactly, and this is what we want from COSC! This is central to alfresco, sugar crm, jboss, etc. You have to foster the community, nurture it until it is as much in the drivers seat as you are. IBM understands this well. However, the seem to maintain a balance of influence in terms of vision for the product. This is because they intend to sell service not product.