I see that Sun has set up an Open Source Office in a further attempt to bring some coherence to their strategy and tactics for relating to the open source phenomenon.

This kind of activity can be viewed from different frames. I, for example, haven’t the qualifications to view it thru the Java frame. But let me comment on it from two frames I think I understand pretty well.

Sun has done some reasonably clever standards moves over the years. As a technology/platform vendor the right way to play the standards game is to use it as a means to bring large risk adverse buyers to the table. Once you got them there you then work cooperatively with them to lower thier risks and increase your ablity to sell them solutions. Since one risk the buyers care about is vendor lock-in (and the anti-trust laws are always in the background) the standards worked out by these groups are tend to be reasonably open. Standards shape and create markets. Open enables vendor competition.

This process is used to create new markets, and from the point of view of the technology vendor that requires solving two problems. First and foremost it creates a design that meets the needs of the deep pocket risk adverse buyers. Secondly it creates a market inside of which the competition is reasonably collegial. The new market to emerges when you get the risk percieved by all parties below some threshold.

Open source created a new venue, another table, where standards could be negotiated. Who shows up at this table has tended to be different folsk with different concerns. That’s good and bad.

The open source model works if what comes out of the process is highly attractive to developers (i.e. it creates oportunities for them) and the work creates a sufficently exciting platform that a broad spectrum of users show up to work collegially in common cause to nurture it.

The goals of the two techniques are sufficently different that both approachs can use the word open while meaning very different things. It has been very difficult for Sun to get that. For example the large buyer, risk reducing, collegial market creating standards approach talks about a thing called “the reference implementation” and is entirely comfortable if that’s written in Lisp. The small innovator, option creating, collegial common cause creating standards approach talks about the code base and is only interested in how useful as feedstock for the product they are deploying yesterday.

It’s nice to see that Sun has created an Open Source Office; it’s a further step in coming to terms with this shift in how standards are written and the terms that define the market are negotiated. But, my immediate reaction was: “Where’s the C?” as in CTO, or CIO, etc.

What does the future hold. Will firms come to have a Chief level officer who’s responsible for managing the complex liason relationships that are implicit in both those models of how standards are negotiated? I think so. This seems likely to become as key a class of strategic problems as buisness development, marketing, technology, information systems, etc.

Open source changes the relationship between software buyers and sellers. It has moved some of the power from firm owners and managers down and toward the software’s makers and users. But far more interestingly it has changed the complexity of the relationship. The relationship is less at arms length, less contractual, and more social, collaborative, and tedious.

This role hasn’t found a home in most organizations. On the buyer side it tends to be situated as a minor subplot of the CTO’s job; while of course the CIO ought to be doing some as well. On the seller side it’s sometimes part of business development or marketing even. That this role doesn’t even exist in most organizations is a significant barrier to tapping into the value that comes of creating higher bandwidth relationships on the links in the supply chain.

This isn’t an arguement about what the right answer is because the answer is obvious some of both models. Some software will be sold in tight alignment with carefully crafted specifications and CIOs will labor tirelessly to supress any deviance from those specs. Some will be passed around in always moving piles of code where developers and users will both customize and refactor platforms in a continous dialog about what is effective. The argument here is about how firms are going to evolve to manage the stuff in the second catagory. That’s not about managing risk, that’s about creating, tapping, collaboratively nurturing opportunities.