One of the benefits of working on an Eclipse project is that you get to see firsthand how open source is produced and consumed. In a series of "Antipattern" posts, I will talk about some things you don't want to do with open source: sort of like a set of "worst practices."
For the first installment, let's talk about how to consume open source components in a commercial product. The lack of a viable consumption process is one of the biggest problems I've seen, and is most severe when the company consuming the components is also working on that open source project. That last bit is counter-intuitive: if your company is working on open source components that you also consume, shouldn't it be easier to manage the quality, features, timing, etc.? In some circumstances, yes, but crucially it all depends on your consumption process. This process has an impact on how you participate in the open source project and how attractive it will be for others to join your efforts.
The heart of the problem is binding commercial products too tightly to open source components. When you do so, you expect that the open source components will work in a way that you alone have determined necessary for your product, and that they will evolve in a controlled path aligned with product aims. Yet sharing in open source goes beyond simply making source code available. It goes beyond the other associated transparency areas (bug lists, development mailing lists, etc.). That is, success open source is about sharing control of the components as well. If you really want an engaged community to rally around your open source efforts, you have to share control, otherwise you limit how much people can actually participate, in ways meaningful them, in your project.
Now, here's the rub: when you share control, sometimes the open source components will move in a direction not aligned with your product goals. If your products are very tightly bound to the open source components, then you'll either have to accept the loss of control or stop using the components to regain full control.
With a better consumption plan, however, you can enable the best of both sides: control over your product while allowing the open source to move with the community. What you need is a process that is flexible and that can adjust the open/closed source mixture as necessary. You should also consider the wisdom of crowds: if the community is moving the open source components in a certain direction, perhaps that's better than what you had previously considered for your product? Perhaps you're getting hyper-early beta feedback at a time when you can actually react to it?
Whatever you do, don't stifle an open source project with commercial product goals and then wonder why a strong community hasn't developed around either.
Monday, October 1, 2007
Wednesday, May 9, 2007
Code wants to be miscellaneous
I’ve been reading the fascinating Everything is Miscellaneous by David Weinberger, and have a few preliminary ideas about how this relates to open source. The final two sentences of his prologue: “…information doesn’t just want to be free. It wants to be miscellaneous.” I’d like draw out an implication of this statement:
Code doesn’t just want to be free. It wants to be miscellaneous.
So, what’s that supposed to mean? I’m only going to make a few suggestions here, as I best understand it at the moment, and leave the implications to more study and discussion of Weinberger’s book.
Open source code is free, as we all know, like in “free speech” not “free beer." Well, it is free in this sense modulo the open source licenses morass, but that’s another post… But it is not "miscellaneous" in the sense that Weinberger uses it. For him, an important characteristic of information being miscellaneous is the ability to recombine it in ways desired by the consumer of that information. Information is allowed be an unstructured, unordered, teaming mass with rich associations. Consumers of this information take slices configured according to their wishes, and in the process both create additional information and associations.
I wonder if open source can get to this miscellaneous state? A state in which components, source files, and even parts of source code itself can be recombined as desired by consumers, and in which rich meta-data enables this usage. An example from Eclipse: there are feature definitions which bundle plug-ins into groups based on usage patterns or functional areas. While the feature mechanism is a great tool, anyone who has provided Eclipse plug-ins to enough adopters can tell you that no set of feature definitions will ever satisfy everyone. There’s just too many ways to slice and dice plug-in sets, even in smaller projects, and by the time you get to the size of most Eclipse Foundation top-level projects, the possibilities are huge. In practice most adopters just take the best approximation of their needs based on existing features, though some apparently define their own custom feature definitions. In this system, the plug-in set is structured into features at the wrong end (following Weinberger’s theory): the providers are imposing what they feel to be the appropriate feature set on adopters, whereas it should be the adopters who are defining features as desired. And I don’t mean the adopters suggest a new feature set to the Eclipse project: I mean that the adopters dynamically create their feature sets based on their needs as the moment.
Another example: what if there were an open source project where anyone could modify the code? I don’t mean “submit a patch” or “modify their local copy,” but rather an open source project where anyone could commit changes. You say that this would quickly become chaos? The code would never run? Security bugs could be injected on purpose? How can the quality/intellectual property be managed? Yes, these are real concerns today. But, to me, this points to the need for a new set of tools and a new way of working with source code. One which lets me understand the lineage, modifications, and intent of various “layers” (versions) within the miscellaneous code base. One which lets me have the stability demanded by (especially commercial) adopters, with the free-flowing experimentation of an ideal(istic?) open source community.
I can see two objections here: this whole “miscellaneous” business is a sham, and arguments that we can/are doing so already. Maybe the first objection is correct, but I’d reserve judgment until the ideas and implications of Weinberger’s book are better understood. Personally, I doubt this is a sham: on the contrary, it is pointing to something very important. For the second, I’d agree in theory, if not practice. In other words, in is possible, but not at all practical, to do these sorts of things with existing technology. But that’s not the point: the reason why we’re not still writing everything in assembly language, for example, is that higher-level languages bring abstractions and enable thinking in different ways. The same is true here: we need tools working at the right “level” so miscellaneous information can be harnessed on a routine basis, without requiring large effort, knowledge or time.
Code doesn’t just want to be free. It wants to be miscellaneous.
So, what’s that supposed to mean? I’m only going to make a few suggestions here, as I best understand it at the moment, and leave the implications to more study and discussion of Weinberger’s book.
Open source code is free, as we all know, like in “free speech” not “free beer." Well, it is free in this sense modulo the open source licenses morass, but that’s another post… But it is not "miscellaneous" in the sense that Weinberger uses it. For him, an important characteristic of information being miscellaneous is the ability to recombine it in ways desired by the consumer of that information. Information is allowed be an unstructured, unordered, teaming mass with rich associations. Consumers of this information take slices configured according to their wishes, and in the process both create additional information and associations.
I wonder if open source can get to this miscellaneous state? A state in which components, source files, and even parts of source code itself can be recombined as desired by consumers, and in which rich meta-data enables this usage. An example from Eclipse: there are feature definitions which bundle plug-ins into groups based on usage patterns or functional areas. While the feature mechanism is a great tool, anyone who has provided Eclipse plug-ins to enough adopters can tell you that no set of feature definitions will ever satisfy everyone. There’s just too many ways to slice and dice plug-in sets, even in smaller projects, and by the time you get to the size of most Eclipse Foundation top-level projects, the possibilities are huge. In practice most adopters just take the best approximation of their needs based on existing features, though some apparently define their own custom feature definitions. In this system, the plug-in set is structured into features at the wrong end (following Weinberger’s theory): the providers are imposing what they feel to be the appropriate feature set on adopters, whereas it should be the adopters who are defining features as desired. And I don’t mean the adopters suggest a new feature set to the Eclipse project: I mean that the adopters dynamically create their feature sets based on their needs as the moment.
Another example: what if there were an open source project where anyone could modify the code? I don’t mean “submit a patch” or “modify their local copy,” but rather an open source project where anyone could commit changes. You say that this would quickly become chaos? The code would never run? Security bugs could be injected on purpose? How can the quality/intellectual property be managed? Yes, these are real concerns today. But, to me, this points to the need for a new set of tools and a new way of working with source code. One which lets me understand the lineage, modifications, and intent of various “layers” (versions) within the miscellaneous code base. One which lets me have the stability demanded by (especially commercial) adopters, with the free-flowing experimentation of an ideal(istic?) open source community.
I can see two objections here: this whole “miscellaneous” business is a sham, and arguments that we can/are doing so already. Maybe the first objection is correct, but I’d reserve judgment until the ideas and implications of Weinberger’s book are better understood. Personally, I doubt this is a sham: on the contrary, it is pointing to something very important. For the second, I’d agree in theory, if not practice. In other words, in is possible, but not at all practical, to do these sorts of things with existing technology. But that’s not the point: the reason why we’re not still writing everything in assembly language, for example, is that higher-level languages bring abstractions and enable thinking in different ways. The same is true here: we need tools working at the right “level” so miscellaneous information can be harnessed on a routine basis, without requiring large effort, knowledge or time.
Wednesday, May 2, 2007
Do software commodities exist?
The word “commoditization” often comes up in reference to software [one example], especially open source software. The standard notion is that a particular class of software becomes commoditized when there are a number of equally good substitutes. If the software is offered free of charge, then cost strategies based purely on that software itself are not tenable. We tend to think about commoditization as a one way, final process: once a specific type of software is commoditized, it remains so. And, for obvious reasons, those who commoditized the software and those who built on it are happy to sustain this permanent state.
Yet the word “commodization” obscures important perspectives. For example, at EclipseCon 2007, Brent Williams argued that the software market is not a commodity market. His presentation is excellent reading for this and the other points it makes, and has been widely noticed in the Eclipse community. How can we account for the widespread notion of software commoditization in light of Brent’s argument? In my opinion, there are two things going on here. First, the software market as a whole does not behave like a commodity market (as Brent says), but there are specific types of software that do, for certain classes of consumers/users. Simply put, there are certain software components that I would never be able to justify to management building another version of, simply because the existing (often open source) alternatives are good enough for our needs and we do not seek to differentiate based on that particular type of functionality. Secondly, I think the word “commodity” (and its variants) is used in at least two different ways: the technical, investment world usage that Brent cites, and the more broad sense of good enough, undifferentiated functionality. Maybe the second usage would be better phrased as something like “soft-commodity,” but it far too pervasive to change.
Another aspect of commodization is the perceived permanence. In their book, The Innovator’s Solution, Christensen and Raynor argue that commodization is a cyclic process, one which includes de-commodization.* De-commoditization: the word is uncommon and probably strange to most of us. But their model is detailed, backed by thorough research, and very important for the software industry to understand. The key claim is that commodization is accompanied by de-commodization at some location in the Value Chain. Thus, it is vital to predict where de-commodization will occur and to prepare for it, which allows reaping profits from the new opportunity.
The notion of de-commoditization might be unfamiliar, but it has appeared before in a number of cases. An early analysis using this term is found here, which (interestingly) is discussing the suggestion of a de-commodization tactic in the famous Halloween Memo. Unlike the specific lock-in protection tactic mentioned there, however, Christensen and Raynor’s model is much deeper and has many more implication for how we think about open source, especially business models/strategies associated with open source software.
* The relevant chapter is also available as a HBS Press Chapter (#1542BC)
Yet the word “commodization” obscures important perspectives. For example, at EclipseCon 2007, Brent Williams argued that the software market is not a commodity market. His presentation is excellent reading for this and the other points it makes, and has been widely noticed in the Eclipse community. How can we account for the widespread notion of software commoditization in light of Brent’s argument? In my opinion, there are two things going on here. First, the software market as a whole does not behave like a commodity market (as Brent says), but there are specific types of software that do, for certain classes of consumers/users. Simply put, there are certain software components that I would never be able to justify to management building another version of, simply because the existing (often open source) alternatives are good enough for our needs and we do not seek to differentiate based on that particular type of functionality. Secondly, I think the word “commodity” (and its variants) is used in at least two different ways: the technical, investment world usage that Brent cites, and the more broad sense of good enough, undifferentiated functionality. Maybe the second usage would be better phrased as something like “soft-commodity,” but it far too pervasive to change.
Another aspect of commodization is the perceived permanence. In their book, The Innovator’s Solution, Christensen and Raynor argue that commodization is a cyclic process, one which includes de-commodization.* De-commoditization: the word is uncommon and probably strange to most of us. But their model is detailed, backed by thorough research, and very important for the software industry to understand. The key claim is that commodization is accompanied by de-commodization at some location in the Value Chain. Thus, it is vital to predict where de-commodization will occur and to prepare for it, which allows reaping profits from the new opportunity.
The notion of de-commoditization might be unfamiliar, but it has appeared before in a number of cases. An early analysis using this term is found here, which (interestingly) is discussing the suggestion of a de-commodization tactic in the famous Halloween Memo. Unlike the specific lock-in protection tactic mentioned there, however, Christensen and Raynor’s model is much deeper and has many more implication for how we think about open source, especially business models/strategies associated with open source software.
* The relevant chapter is also available as a HBS Press Chapter (#1542BC)
Tuesday, March 13, 2007
Purpose of this blog
This blog is a spin-off from my previous one concentrating on the Eclipse Data Tools Platform (DTP) project. In that blog I've mixed in discussion of open source in general with DTP posts. Based on my recent presentation at EclipseCon 2007 (The Garden & the Market), I feel it is time to separate these discussions, and hence this new blog.
So, what sorts of things will we discuss here? As an initial estimate, here's some links to posts on the Data Platform blog covering the intended topic areas:
So, what sorts of things will we discuss here? As an initial estimate, here's some links to posts on the Data Platform blog covering the intended topic areas:
Adminstrative Notes
The postings on this site do not represent positions, strategies, opinions, etc. of Sybase, Inc., the Eclipse Foundation, or the Eclipse Data Tools Platform (DTP) project.
Subscribe to:
Posts (Atom)
