Sun and corporate open source
It all started with a posting by Ted Ts'o which stated:
The posting drew responses from Dave Neary and Alvaro Lopez Ortega, among others; both the original messages and the responses to it are worth reading in their entirety. In summary, the responses say that (1) Sun really is trying to be a good open source player, and (2) Sun has done as well as could be expected, that the creation of true open source communities is hard.
The first part can only be true. Sun has been the source of a great deal of free software, including packages like OpenOffice.org which are found in almost every Linux distribution. This company has released its core operating system as open source, and it is making noises about, finally, making Java truly open at all levels. There are few companies which have contributed code at this level, and that should be recognized. Beyond any doubt, Sun is contributing to this community.
What people question, though, is Sun's interest in creating real communities around its open source projects. These projects are notoriously hard to participate in and contribute to. As Ted points out, OpenSolaris currently gets less than one patch per day from outside the company, the project's governing board is made up entirely of Sun employees, and its (non-distributed) revision control system lives inside the Sun firewall. External OpenSolaris developers have known to quit with messages like:
OpenOffice.org, too, remains hard to work with; thus the many discouraged comments on the ooo-build wiki from developers who want to get things done:
The key to what is going on here can be found in many places, including in Alvaro's posting:
The real issue is control; Sun does not want to relinquish control over how its projects evolve. This is not a particularly uncommon situation with corporate-controlled projects; these projects will always be subject to the controlling company's agenda. Thus, no developer is likely to be successful in projects like:
- Adding features to MySQL which provide the functionality which is
otherwise being reserved for the "enterprise" offerings.
- Adding packages to Fedora which make Red Hat's legal department
nervous.
- Adding features to projects owned by the Free Software Foundation
which, in the FSF's opinion, are not consistent with its goals;
support for loading Emacs modules from an external repository is one
example.
- Making any changes to Firefox which could threaten Mozilla Corporation's revenue stream from Google.
Companies which control open source projects in this way are generally acting within their rights; they may even be acting in their own best interests. The software is still open source. But the retention of this sort of control will have an effect on the community which builds around the software. In many cases, it can have the effect of preventing the creation of that community in the first place.
And that, too, may be what the company had in mind. There are a number of company-controlled open source projects which, by all appearances, are mostly for show and bragging rights. The company does not really seem to have much interest in developing a significant external community. In cases like this, if the software on offer is valuable enough, the result will often be a more community-oriented fork. Projects like ADempiere, LedgerSMB, and Cinelerra CV result from this kind of frustration.
Opinions clearly differ on whether Sun is truly uninterested in the
creation of outside development communities for its projects, or whether it
simply is having a hard time letting go. If the latter is the case, then
Sun might be well advised to follow Dave
Neary's suggestion and create a separate, non-profit foundation for the
development of OpenOffice.org. Sun's apologists are right when they say
that turning a large blob of proprietary code into free software is a hard
thing to do. But it's harder if you don't give the community the power to
help; in the case of OpenOffice.org, there would appear to be enough of an
interested community to make a real go at it. This might be Sun's best
chance to show that it can create real development communities
around its software.
Posted May 1, 2008 1:05 UTC (Thu)
by movement (subscriber, #871)
[Link] (3 responses)
Posted May 1, 2008 2:36 UTC (Thu)
by rahulsundaram (subscriber, #21946)
[Link] (2 responses)
Posted May 1, 2008 2:45 UTC (Thu)
by movement (subscriber, #871)
[Link] (1 responses)
Posted May 1, 2008 8:22 UTC (Thu)
by rahulsundaram (subscriber, #21946)
[Link]
Posted May 1, 2008 5:32 UTC (Thu)
by botsie (guest, #1485)
[Link] (2 responses)
Posted May 1, 2008 8:02 UTC (Thu)
by jschrod (subscriber, #1646)
[Link] (1 responses)
Posted May 1, 2008 12:58 UTC (Thu)
by movement (subscriber, #871)
[Link]
Posted May 1, 2008 7:53 UTC (Thu)
by edschofield (guest, #39993)
[Link] (1 responses)
Posted May 1, 2008 13:46 UTC (Thu)
by janneke (guest, #15012)
[Link]
Posted May 1, 2008 11:30 UTC (Thu)
by man_ls (guest, #15091)
[Link]
Posted May 1, 2008 14:02 UTC (Thu)
by roblatham (guest, #1579)
[Link]
Posted May 1, 2008 17:14 UTC (Thu)
by vmole (guest, #111)
[Link] (1 responses)
Another very important technical point is that we want OpenSolaris to continue being binary compatible (ABI) with the previous Solaris revisions...
What has that got to do with whether or not you support and encourage outside developers? That's just a limit on what a patch can do, just like Linus won't accept patches that break the system call interface.
Posted May 1, 2008 18:14 UTC (Thu)
by smoogen (subscriber, #97)
[Link]
Posted May 2, 2008 11:05 UTC (Fri)
by Jaffa (guest, #4327)
[Link]
Posted May 3, 2008 18:52 UTC (Sat)
by KaiRo (subscriber, #1987)
[Link]
The big difference here is that Sun is, of course, a company driven by making the most possible profit for its shareholders (who want to see that profit in money), so (it thinks) it needs to keep control of things to ensure this goal can still be reached (and this goal is of course not what drives an open source community). The Mozilla Corporation on the other hand has only one shareholder, it is a 100% subsidiary of the Mozilla Foundation, so it needs to make the kind of profit the Foundation wants. Now that Mozilla Foundation is a non-profit, mission-driven organization. It does not want the most possible money from the Corporation, it wants to see its mission succeed. That mission is the Mozilla Manifesto, which was chosen in a community process with the help of lots of "external developers", i.e. non_mozilla-employees, to extend and better describe the meaning of the early mission statement, which was to preserve choice and innovation on the Internet. Now, if any proposal comes along that would play out the revenue stream that the Mozilla Corporation gets through e.g. Google against the Mozilla Foundation mission, i.e. the Mozilla Manifesto, you can bet that even if the first choice would be trying to fit both goals, in the end the Manifesto would win. That's why you can, if you want, delete every usage of the Google search by your Firefox installation, and the Mozilla employees even will help you as part of their job if you find there's some place where this isn't possible. Mozilla puts the value of the mission, which is basically a better and continuously really open Internet, above the value of money. It's just a good thing that there is obviously a way to earn money by following the mission, which in turn can be used for spreading the mission even more. And this is very compatible with an open source community.
Posted May 5, 2008 22:00 UTC (Mon)
by kov (subscriber, #7423)
[Link]
Roy Fielding
Roy Fielding was not an OpenSolaris developer: he never contributed any
code to the project (or tried to).
(He was involved, yes, but it's not like the project lost a hacker.)
Roy Fielding
"Developers" aren't merely those who contribute code. Any good contributor (management,
packager, translator, artists etc) to a project can be viewed as a developer and the loss of
any of them can and in many cases does have a higher impact than a "hacker". Dismissing their
contributors doesn't do us any good.
Roy Fielding
Sorry, no. A software developer is someone designs, writes, or fixes software.
There are many other ways to contribute, as you point out. But Roy wasn't a developer on
OpenSolaris, and the correction I made stands.
Roy Fielding
The article refers to opensolaris developers. From a project perspective, this doesn't confine
to just software developers but everybody involved in the project. Package maintainers
wouldn't necessarily count as developers possibly by using a strict definition since their
primary task isn't designing or writing software but they are widely regarded as such and term
is used more loosely. You view point seems different.
Sun and corporate open source
> As Ted points out, OpenSolaris currently gets less than one patch per day
> from outside the company, the project's governing board is made up
> entirely of Sun employees, and its (non-distributed) revision control
> system lives inside the Sun firewall.
Minor quibble: Sun's internal VCS is Teamware, which is an early distributed version control
system designed by Larry McVoy before he wrote BitKeeper.
See: http://en.wikipedia.org/wiki/TeamWare for details.
Sun and corporate open source
Huh? The Sun folks that I know and work with tell me that Solaris VCS has moved largely to
Mercury by now. I dunno about Java, don't know any of these folks.
Sun and corporate open source
The Solaris kernel + stuff gate is still Teamware, with a real-time Mercurial read-only bridge
(which is publicly available to all). To make changes, you have to use Teamware. This is why
the request-sponsor process exists.
What's holding ooo-build back?
Surely rancour over the need to fork belongs to the bad old days of centralized revision
control systems.
Why doesn't ooo-build use git/hg/bzr with a branch to track the upstream OpenOffice CVS and go
go go? We could all be using ooo-build in a few months if it were the more dynamic project.
What's holding ooo-build back?
ooo-build is already a fork with some 800 patches. The question
is: should ooo-build now work hard to fork the community? There's
something to say for working with SUN instead of against them.
Surely rancour over the need to fork belongs to the bad old days of
centralized revision control systems.
OpenOffice.org is big, even for git.
Kendy has been doing some grand git testing and profiling the past year
and has been submitting patches to git to up cloning performance.
Then, there are discussions about what to do with the ~800 patches
in ooo-build. As most of these should go "upstream" (read: to SUN),
one feature a time, should we have 800 branches? And how to manage these?
Scripts, new git features?
Why doesn't ooo-build use git/hg/bzr with a branch to track the upstream
OpenOffice CVS and go go go?
It already is the more dynamic project, esp. for developers and
we already *are* all using ooo-build. Well, technically maybe not if you're still using Fedora (has its own fork, taking their own set of patches from ooo-build, hysterical raisins), but all other distros are
working with Novell and ooo-build.
Ah and of course it's not "go go go", but rather GO-OO ;-)
We could all be using ooo-build in a few months if it were the more
dynamic project.
If Sun creates a foundation for OpenOffice.org development external people might contribute, not only with patches but financially as well. IBM has largely done this with the Eclipse foundation and by now it has built a huge momentum. Compare with Sun's NetBeans which is apparently better software, but is not so popular by far within the Java ecosystem.
OpenOffice.org foundation
Sun and corporate open source
You can add the distributed file system Lustre to the list of sun-sponsored
source-available projects.
In addition to issues of control, it's a tough balance to strike when your
revenue model is to give away the software and sell support. A lot of
responses on the lustre mailing list are along the lines of "we'd be happy to
fix that. Please contact us about a support contract".
You can give away source code (and Lustre is under the GPL), but open
development is an important component of successful open source projects.
I Call Shennanigans
I Call Shennanigans
Actually it should mean any patch has to run through a large test suite to make sure it does
not break ABI, API, or other tests.
Sun and corporate open source
This is very similar to the situation with Nokia's Maemo-based Internet Tablets (e.g. the 770,
N800, N810 and N810W). It's an open source base but with very little community involvement,
exactly because Nokia want too much control.
I wrote something about this, including what I've termed the "open source triangle": Community
involvement, Openness and Control are all pulling in different directions:
http://www.maemopeople.org/index.php/jaffa/2008/04/20/mae...
Of course, OpenSolaris and OO.o are much bigger projects - and more important to Sun - than
Maemo is to Nokia, but it's interesting to see both these big companies have very similar
problems.
It's hard to go by as a Mozilla insider and not comment on your point of
Sun and corporate open source
Making any changes to Firefox which could threaten Mozilla Corporation's revenue stream from Google.
So here it is:
Apple seems to be doing a very nice job
This really is something I would not expect saying anytime soon, but Apple does seem to be
doing a very nice job with WebKit at this time. It seems like they have had a hard time with
KHTML developers a while ago, but it is impressive to see that they have an open Trac, SVN,
wiki, and that the collaboration model does seem to be very open, with people from the outside
having commit rights and being able to design their own APIs.