Creative Commons License

Blog powered by Typepad

« Book Burning in the New Millenium | Main | A New Blog about Big Data in the Cloud »

22 March 2010


Jack Repenning

Any idea why Matt continues to ignore the most successful and profitable business-to-OSS relationship, "Open Infrastructure"? That is, fostering and contributing to a community OSS project that produces something you need, so you can get on with whatever you want to do? This is how most participants relate to Linux, for example; not to mention how *all* participants relate to Apache projects.



As I answered when you asked a similar question before this is actually covered in the explanation of this slide, but it not explicit within it. The strategy you describe would be covered by the "open complement" licensing strategy, in our model.


P.S. Thanks for blogging this Stephen

Jack Repenning

Sorry I missed your earlier response, Matt. But I don't think Open Infrastructure should be lumped as a subset of Open Complement. There are many big differences between

- creating a (possibly proprietary) core platform where others contribute open-source value (one part of your open-complement space).

- supporting an open community that openly creates something you need, in order to provide your own (possibly proprietary) product on top of it.

Consider, for example, the companies whose employees contribute to Apache projects, like httpd or Subversion. None of them is selling the project output, yet all the web depends on infrastructure components like these. Companies contribute to these projects because they believe they can make more money in a world that has these resources.

This is very different, in many ways, from creating a community that can openly expand and extend on your base product.

Because these terms describe the relationship between a company and a project, and large projects involve many companies, some companies will have one relationship while others have another. When Red Hat, for example, contributes to RHEL, there's an "open complement" aspect to the strategy: Linux is a platform for doing other things, and most people who use Linux use it to do other things: to complement the core.

But when another company contributes to Linux, they may be doing it to create infrastructure on which they depend. They may fix a kernel crash, for example, because they've found it keeps crashing while running their product, and people don't like to pay for products that make the kernel crash.

Another distinction is almost too obvious to mention: if your "openness" is "openness to others creating stuff that can only run on my platform," your contributions are still pretty enclosed. But if your "openness" is "contributing to open projects that help everyone," then you're open in many dimensions.



I would agree the approach you describe is not covered in our model. Part of my reason for presenting this was to engage in conversation and highlight flaws in the model that can be fixed ahead of our report being published later this year. In my presentation I talked a little about different strategies that are subsets of Open complement - providing a proprietary product on top and using open source to drive innovation around a proprietary product, for example. Those are also not explicitly represented in our model. I think at a practical level they may be a level of detail beyond the scope of the model, but I will investigate how they could be added. If you have any suggestions, I'd be happy to hear them.


The comments to this entry are closed.