The Trouble With Open Source

I was talking with a friend of mine not long ago about Sun's plans to "open source" Solaris

By the way, I find it amazing that "open source" is a generally accepted verb phrase, sort of like using the word "target" when somebody really means "aim" or "architect" to say "design".  Not with me on this one?  Go ask an archer what word she uses to describe the process of pointing the arrow at its destination, then go ask an architect what word she uses to describe the process of doing her work.  Betcha she doesn't say "I architect".  But I digress...back to the Solaris-as-open-source thing.

Anyway, after talking to my friend about Sun's plans, I think I understand why we are going to put Solaris into the open source community.  But I want to make sure we're doing it for the right reasons, because open source has some properties that can seriously get in the way of solid, quality product development.  And if there's ever a product that I don't want ruined, it's Solaris, because Solaris is a pretty damned rock-solid product.   To understand where I'm coming from, here's some background on me.

I currently work in Sun's Market Development Engineering (MDE) organization, which means I work with some of Sun's key software partners.  What that really means is that I get to see how Sun's products affect the ability of our partners to sell their own software to customers; I have to think about how our partners generate revenue that drags Sun revenue with it, and I have to think about how Sun's products (direction and quality both) affect that partner revenue, and therefore indirectly affect Sun's revenue.

Before this gig, I worked in one of Sun's software product groups; I was Mr. Browser Guy (that's code for "browser engineering manager").  Our group (lead by this fine man, whose blog you may have read once or twice) was responsible for taking the Mozilla browser and turning it into product on Solaris.  (by the way, if you're in Sun engineering management and you want product to get out the door and need a lead engineer to do it, Rich is definitely your man.  The guy can get product shipped, let me tell you.)  My VP at the time was this guy, the first person I saw in a while who really had a passion for an integrated desktop strategy for Sun.  We got him in the acquisition of StarOffice. He drove me crazy at times and nearly gave my manager at the time a nervous breakdown, but the guy is smart, driven, and passionate, and I respect him for that.  I'm glad to see Jonathan picking up the ball on the desktop vision.  I would love to have been a fly on the wall in any conversation between Jonathan and Marco.  I bet sparks would've flown, and maybe not for the right reasons because my belief is that they share similar fundamental beliefs about Sun and our ability to make a significant desktop offering to the public.

Anyway, I work with partners now, I worked on an open source browser before and turned it into product, and I believe these two things give me a valid perspective on the nature open source and product development.

A question that our partners frequently ask us is whether they can count on Sun for support when the partner's customer has problems with software we ask the partner to use.  In the case of browsers, we ask our partners to support the Mozilla browser because it runs on Sun platforms and runs quite well nowadays.  Problem is, Mozilla is an open source browser with no commercial entity on the hook for providing support for any given bug.  Partners get nervous about that: what do they do if a customer reports a bug, it  turns out to be a bug in an open source component like the browser, and there's no throat to choke (unless you have a Svengali-like sway in developer IRC chat rooms).  Fortunately for our partners, Sun invests heavily in Mozilla support by supplying dedicated software engineering to the Mozilla project, and we take responsibility for the Solaris port of Mozilla.  If Mozilla bugs happen on Solaris, our partners can go to us.  Same with StarOffice, by the way, and I expect the same will happen with Solaris when it is in the open source.

I used to spend every Wednesday at Netscape and was amazed at the good, the bad, and the ugly of it all.  The good, amazingly good, was how transparent Netscape folks were with us about their product development process.  They treated us like true partners --- closer, really --- at the time we worked with them.  If making browsers is like making sausages (you love the product but really don't want to see how they're made), we were right there in the sausage factory.  The bad was how many problems the browser had at the time: tens of thousands of bugs in a product (Netscape 6) that shipped much later than everybody hoped and probably earlier than it should have shipped.  The ugly had to do with the tension between building an open source browser and building a product.  And here, my friends, is where I think the problem is.

Open source development is about making the development tree available to the maximum number of developers possible.  Some open source projects severely limit the number of developers who are effectively allowed to contribute, but overall if you have open source, you want to attract developers. This was the case with Mozilla: they wanted as many developers to contribute as possible.  You thus create a set of rules and procedures that encourage developers to get your source, build it, play with it, and contribute your stuff.  The lower the barrier to developers, the more developers you'll get making contributions.  That's great leverage, but you have to make some compromises in order to lower the barrier to developers.  The first compromise is usually quality.

Product development, on the other hand, is all about increasing the barriers to development the closer you get to shipping product.  Product development always fights the features/schedule/quality multi-variable problem, but at the end of the development cycle, product groups ratchet up the barriers to make it harder and harder for the developers to make changes.  Change equals risk, and you don't want to be adding risk at the last minute, when you're about to try to deliver a final build to the product people to do all the things they do to get that product shipped (QA, download readiness, documentation, marketing collateral, etc.).

So to summarize:

Open Source: maximize the number of contributors

Product Development: minimize the number of developers allowed to make changes before shipping

These two goals are antithetical, and I saw it turn ugly when trying to take an open source product and turn it into product by Sun's fairly stringent software product release rules.

Given this, why is it a good idea to put Solaris into the open source community?  It can't be simply for the purpose of adding features more quickly.  In my opinion, the stability of the product far outweighs the limited number of additional contributors I believe we'd get adding new features anyway.  I'm not even going to address the forking problem (how many versions of the OS would there be out there?  How many branches of the Mozilla source are out there?)

Perhaps we're doing this to give our customers choice and control.  Now that argument I can understand: by giving our customers the option of taking Solaris source code and hiring somebody to make changes they specifically need, customers can have the feeling that they have some control over their operating environment.  Whether that control is illusory (as with the perception that people can have control over Linux if they build it themselves) is a different matter; at least the customer now has a choice, and choice is usually a great thing.

So somebody, please tell me that we're not putting Solaris into open source so that we can attract a zillion developers who will add all kinds of great features (and probably a great deal of either instability or headache), but that we're doing it to help our customers get the control they wish to have over an incredibly stable product.  Ultimately, I believe that customers will be fine with using standard escalation mechanisms to persuade Sun to make the changes they need made.  Our partners are perfectly fine with choking Sun's throats (pardon the metaphor; I tell ya, sometimes it feels that way) instead of going directly to the open source community.  I believe most customers will eventually (if not sooner) come to the same realization.

But that's just me.  Keep in mind I'm biased based on a few years of scarring.  Still, I miss our friends at AOL/Netscape.


You may want to take a look at the difference between the Netscape 6 model of development and that of Firefox. The Firefox team basically said "we're NOT going to allow any random Joe Schmoe check into our branch". So the way it works is that lots and lots of developers check into the Mozilla tree, but only high-quality, stable patches go into the Firefox branch.
You don't have to USE every bit of code that gets checked in. As Simon Phipps put it, you have editorial control. As one of the distributions of Solaris (hopefully the one 99% of users use) you get to protect your users from patches that may look good but have not been tested enough.
The hope of an open source Solaris is that this job of editorializing, picking out the good bits from the not-so-good bits, will be a lot easier than writing the good bits yourself. And with your highly technical user-base, I have a feeling you will be flooded with good bits.

Posted by Sebastian Fernandez on September 12, 2004 at 08:31 PM PDT #

Good point, Sebastian, about using open source in an editorial fashion. And when we were working on N6, the check-in model \*did\* become like what you mention in Firefox: there were twice-daily reviews of critical changes and as product ship date approached, fewer and fewer people were allowed to check anything into the main branch. This caused any number of, uh, interesting conversations between the staff (most of whom were AOL/Netscape employees) and the N6 staff (who worked in cubicles right there with the Moz staff). There was a constant, uh, dialog, about whether to relax or tighten the rules. It was tough to watch and tough to see if they got it right. If things happen as you suggest, somebody (or a group of somebody's, like Mozilla "super-reviewers") going to be very busy looking at other people's code. I wonder if we at Sun will limit the barriers to simple code reviews, or if we'll impose more stringent processes like the ones the internal product groups use (essentially, producing documents beforehand stating what the project will be, why, resource estimates, etc.) for contributions other than simple bug fixes.

Posted by George Drapeau on September 13, 2004 at 02:58 AM PDT #

Post a Comment:
Comments are closed for this entry.

The views expressed on this blog are my own and do not necessarily reflect the views of Oracle. What more do you need to know, really?


« July 2016