I goofed a bit in my previous blog about open core / open source licensing. As always, the details are full of devils -- but that afforded a chance to bring some more thought to the table.

Not long after I made the post I got feedback from 451 Group fellow Matt Aslett himself as follows:

I did not state that vendors should use a custom open source license. What I was saying that they should continue to use the proprietary license for non-core code but be prepared to give up any claim to calling themselves an "open source vendor" in the light of a potential plan for the OSI to approve certain business practices (with open core unlikely to meet approval).

Point taken, and that spurs some additional musing: To what extent will it be important to be classified as an "open source vendor" in the future, when open source (presumably) becomes more a part of the rest of the software landscape and its merits become one set of merits among many? It's a view that other people have touched on as well -- the distinction between open and closed will matter less to a buyer than the feature set; it'll be just one characteristic among many.

If you call yourself an open source vendor now, and adhere to the behaviors one would expect from something with the label, that's one thing -- but years from now, there may be a great deal less need to win such approval. I hope this doesn't in turn lead to a dilution of the term, where "open source vendor" becomes denatured in meaning, and people don't work as hard to earn the term because it doesn't mean as much anymore.

You have also overlooked the critical point of Options #1 and #2 (or 2a and 2b in my analysis), which was that "The open source core should be released under a more permissive license, or better still via an existing community/foundation in order to benefit from and encourage a collaborative development community."

This is quite different from the vendor-dominated approach to open core that most vendors have adopted to date, which has resulted in some of the antipathy from member of the open source community that my suggestions were designed to address.

I admit, I figured this conceit was self-evident, since I've talked about it myself on and off: if you use an existing license or organization for your code you'll get a community right back. Since a community is hard enough to build from nothing, it's often easier to start with one that already exists.

It's a wise plan. But what I wonder is how many people using the vendor-dominated approach are likely to switch to this model, if only because they feel they've already got what they perceive as a "community" (even if it's nothing like the community that thrives around something like, say, Apache or Eclipse). They'll definitely feel the pressure if the people asking for those things are their own paying customers -- but again, that presumes those people are interested in the politics of the situation and not simply in the market for good software. (Of course, the way around this is to show them how much better the software is on the side of the fence where there is a thriving community around a product. That kind of proof always speaks best, doesn't it?)

The InformationWeek/bMighty Data Centers For Growing Companies virtual event explores the latest technology and tools you can use to manage your growing IT needs. Oct. 21, 2009. Find out more and register.

Follow me and the rest of InformationWeek on Twitter.