☝ Open Core MySQL? Contributor Agreements!

Oracle has finally done what the business management at MySQL had been asymptotically approaching for years. It’s taking MySQL open core. It’s interesting to read both Monty’s view and the comments for this one. It’s all on ComputerWorldUK

★ “Which Open Source Licence” Is The Wrong Question

Mesa Verde Cliff Palace DetailVarious commentators are beginning to pick at the threads of the rediscovered collaborative model for open source now that the “open source bubble” is being superseded. This is a return to what many of us regard as “real open source” (the co-development of software by a community of people who align a fragment of their self-interest in order to do so, using their software freedoms under an open source license and open governance).

Glyn Moody asks the question of which open source licence is best for the new wave and comes to the conclusion that the problem that’s faced open source projects in the “bubble” has been less licence choice and more the practice of corporate control via copyright aggregation. I have more to say on this subject in a forthcoming essay.

Glyn’s article has triggered a somewhat strident response from Matt Asay, who picks up a surprising message that I find hard to read in Glyn’s article. He asserts that Glyn (and I) are advocating that the businesses participating in the new collaborative wave should use proprietary software to earn their revenues. This assertion appears to flow from a conviction the only way a business can succeed is by keeping some sort of copyright (or patent) control that creates an artificial scarcity.

I believe the seed of this view is a riff on one of the oldest arguments in software. To comment on it, I first need to get philosophical for a moment.

Cause and Effect

There are two views of the place of “cause and effect” in the world. One believes in direct causality, the other in systemic causality. Both are correct much of the time, so the difference between them rests beneath the surface of most realities. Both are tools in guiding behaviour and predicting consequences.

In most circumstances, direct causality seems the obvious interpretative lens for the past and predictive lens for the future. We are most comfortable when we can draw clear circles around causes and thick lines between them and their consequences. We admire the “chess players” of society who can draw long chains of clear circles and thick lines, and for most of us the ability to mentally calculate chains of cause and effect is limited to only a few steps.

But certain systems involve a longer chain of lesser causes and effects that makes a focus on the individual steps unhelpful. Things like evolution, national economics, global warming and terrorist networks all need a systemic view if they are to be properly understood, and a focus on what the individual can directly prove leads to bad choices. These systems are especially difficult for people with “just do it” attitudes, who find it hard to take “on faith” that they should act in a contrarian way because of a larger system which can’t be seen and computed in its entirety.

When our outlook is dominated by direct causality, we seek control over causes. When our outlook is dominated by systemic causality, we seek influence over the network of causes and effects. In many cases, both outlooks lead to the same decision, but as we have moved to a meshed society, the importance of systemic causality has risen. Every cause has an immediate effect, but to believe that effect is the only consequence is increasingly a risk.

If the distance to the effect we seek is short, and that effect is the only outcome that matters, control is obviously desirable. But if the distance to the desired effect is large and filled with many connections, it’s better to collaborate and co-operate with other participants and prioritise influence over control.

Two Views of Freedom

The tension between direct and systemic causality lies at the heart of the endless debate between whether BSD-ish (permissive) approaches to software licensing are better or worse than GNU-ish (copyleft-based) ones. The GNU-ish view takes a directly causal view, believing that the freedoms of software users are so important that there should be a direct compulsion on every user to share improvements they make to code. Glyn is clearly in the GNU-ish, directly-causal camp, concerned that people may not “give back”:

“This is the classic free-rider problem that the GNU GPL was designed in part to avoid. It means that contributors to Apache-licensed projects must be willing to accept that their work may well end up in closed-source products, maybe multiple times.”

The BSD-ish view is systemic, believing that any innovative user of the code will want to add their improvements to the commons so that the community around the commons will maintain them collectively, freeing the innovator to spend time elsewhere.

This is the view the Apache Software Foundation best expresses, and it clearly works well for them. They have large numbers of participants in a large number of successful projects, and there is no “tragedy of the commons” at work – self-interest does not require selfishness. It is in the interests of every participant to contribute their work to the commons upon which the fragment of their interests relates. Doing so reduces their own costs, increases the surface upon which the community innovates and gives the maximum return. People who don’t add their work to the commons are condemned to maintain their own work, alone, for ever…

Asay makes an unwarranted leap in his description of me in his article. I am a firm believer in the concept and philosophy of software freedom, but that doesn’t mean I believe the only way to achieve it is through directly-causal compulsion. Indeed, I tend to believe that the key to a successful open source project and community is to studiously maintain equality among all the participants so that no one participant can become “more equal” than the others, giving systemic effects free rein.

Contrary to Asay’s accusations, I’m not interested in the sort of “purity tests” into which FOSS fundamentalists spiral; I do, however, object to use of the term “open source” to describe a project where the participants are not all equal-by-rule. The most important factor is not whether it’s OK for community members to create proprietary code from a project; it’s whether everyone has equal rights. I don’t believe creating artificial scarcity through proprietary code is a smart or scalably profitable action, so frankly Asay’s accusation I’m promoting proprietary development aren’t offensive; they are just irrelevant.

So Which Licence?

That’s where the argument of which license to pick needs to follow the sort of logic Carlo Daffera offers rather than the GNU-ish vs BSD-ish path. It’s hard to believe we are still having “which licence is best” arguments eleven years after the founding of OSI, but we are. Arguments over licenses rarely matter these days; all open source licenses are fully gamed. The reason collaborative projects are resurgent is not a “which licence is best” argument at all; it’s a “level playing field vs artificial scarcity” argument.

The reason I believe “Open Core” approaches will become scarcer and scarcer is that the control-freak behaviours they necessitate (like demanding copyright ownership as a precondition of community participation) just don’t lead to the greatest growth. I’m not sure I care much which licence you use, as long as everyone in your community has the same rights so that the most people possible can participate. That’s what will grow the community – and thus the opportunity – for everyone.

[First published on ComputerWorldUK]

✍ Did Open Core Trigger OpenStack?

At the end of the Community Leadership Summit here in Portland people arriving for OSCON started to show up. They included one of the guys behind Rackspace’s announcement of OpenStack that was made today. He gave me a full rundown of both the news and the history behind it. The history seems to suggest it was the open core business model that lead to the creation of OpenStack. Read more on ComputerWorldUK.

✭ On the term “open source business”

Hunter and HuntedI’ve been having a number of conversations in e-mail on the subject of open core business models. The problem that keeps coming up is that there are a range of behaviours exhibited, some of which are acceptable to pragmatists and some of which cross the line into abusing the term “open source”. Where should we draw the line in? When is it acceptable for a company to call itself “an open source business” and when is it not?

An example is a hypothetical  business with an open source “Community Edition” of their software product which lacks many features of the commercial versions. It is indeed freely available under an open source license and fully functional. I am sure there are happy deployers of this version. If this was the only version available, I would have no issues.

The commercial versions are significantly different from the community version, with both user interface differences and functional differences. While paid licensees are entitled to source access to this version, the commercial licence is not perpetual, meaning that if the customer ends their relationship with the vendor, they lose the right to use this version. Since this version significantly differs from the community version, there is no fall-back plan and while the customer may have access to their data (if the vendor is sufficiently enlightened about open data), there’s no software they can continue to use. They are unable to trade “time” for “money”, to use Mårten Mickos’ famous explanation – they are locked in and the open source core of the proprietary version delivers no freedom to them.

If this latter situation was described as “proprietary” (or avoided association with open source, as for example IBM’s WebSphere does in its embedding of Apache HTTPD) I would have no issues either.

The fact is, the community edition and the commercial editions have disjoint user bases. The community edition is used by a group of people who have the time and skills to deploy by themselves and who have no need of the many differences of the commercial versions. The commercial versions are feature-rich and effectively lock their users into a traditional commercial ISV relationship with the vendor.  If these two were kept distinct, there would probably be no pragmatic issue (naturally Free Software purists would still protest the existence of closed code, but that’s not a part of this particular argument).

But a vendor which mixes these two encourages exactly the market confusion that OSI was designed to minimise. If they claim to be “an open source business” and use the presence of the community edition as a credential to sell the proprietary versions, they wrap themselves in the open source flag and their actions are exactly the gaming of the maturity of the Open Source Initiative that I believe should be challenged.

The question is how. As Matthew Aslett points out,

In short, if you want to police the term “open source company” then you have to have a definition for it first.

That’s true. Defining an “open source company” will be impossibly subjective, since most companies have open source in their source code mix these days. Given “open source” can only refer to software, I think is far smarter to discourage use of the term all together.

☞ Open Core Case Study

  • While their marketing guy may claim “that overall, Sugar 6 is an open source product from an open source company”, it’s hard to see how they are anything other than a proprietary software company who share some code with a related open source project. Claiming to be “an open source company” seems an unacceptable use of the open source brand to me. Open Core is bad for you.
%d bloggers like this: