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.