NEW YORK (
) -- I have covered open source software since 2005, and tracked how companies manipulate the rules of open source to suit themselves.
In 2006, I wrote
about what I called the open source incline, the idea being that the more even-handed the license, the more likely it was people would contribute code and other help to a project.
The news peg here was a company called
, which was then gaining significant developer support by licensing its mobile app code under the General Public License, or GPL. This requires that companies offer back their contributions to the code, while the Apache or Eclipse licenses let companies make enhancements proprietary.
In 2008, I wrote
about what I called the open source development incline, the idea being that a project's development model can affect how code contributors react to it.
The news peg here was the battle over
, the open source cloud infrastructure.
had been the original corporate sponsor, but it was then feeling pressure -- to which it later succumbed -- to place the code into a separate foundation that other companies could join.
In 2010, I completed my
on what I called the open source copyright incline. Here, the idea was that where copyright is assigned also matters to contributors.
I wrote this after
tried to use copyright to seize control of open source projects it bought with
. How open is any code, even GPL code, if a company can assert proprietary rights through copyright to what others wrote for it? Fortunately, courts have not seen fit to make open source a dead letter over this claim.
Today it's time for a fourth dimension, which I'll call the access incline. Even if a project is open source, even if it's established, it can collapse if corporate contributors simply decide not to support it, or to restrict support of it by outside developers.
The news peg here is
decision to close out Google Reader,
, close out all support for the Real Simple Syndication, or RSS, standard that Google Reader uses.
The aim, as
, seems clear: to keep users from regularly accessing data outside the Google walled garden.
Controlling access to code is as important as the rules under which code is produced. This is true whether or not the code is open source.
, for instance, wants to control who can access its Social Graph feature,
Wise readers may notice that the company they're all emulating here is
, which first charged 30% of publishers' gross to sell on iTunes.
, a relative start-up, writes at
its company blog
that it is now looking to create a program compatible with the old Reader, and it seems natural to expect the Mozilla Foundation, which produces Firefox, to do the same. This brings us back to the second rule, the development incline, the idea that where the code lives matters.
The important business point is that this can work both ways. Investors may see cutting off open source as a sign of strength, even though a walled garden is as unstable as any other closed ecosystem. But what should investors think when a company goes the other way, when it opens access to code that was previously closed, when it explicitly invites outsiders in?
has done with its Kinect interface,
, making code supporting the interface open source under the Apache License.
Is this a sign of strength or weakness? Most would say weakness. But is this better or worse for open source developers? Obviously it's better.
I think this brings me to some closure on open source policy matters. I first saw the whole thing as euclidean, as a right triangle you could adjust to suit yourself. But it turns out that this is more like quantum mechanics, that there are at least four dimensions under which the rules of open source can be tweaked by companies hoping to seize its value and get some coder love for themselves.
At the time of publication, the author was long AAPL and GOOG.
This article is commentary by an independent contributor, separate from TheStreet's regular news coverage.