I have the good fortune to work for the world’s largest creator of Open-Source software. Big companies being what they are, this means that There Is A Process. Recently, I went through it, and I thought the story might be of mild interest to those who are trying to figure out how to make a living at the intersection of the profit motive and OSS culture.
What happened was that after getting an Atom-Protocol paper accepted at OSCON 2006, I decided that I had to have some actual code to show, so I whipped up a quickie called the Atom Protocol Exerciser, APE for short, and I’ve been whittling away at it ever since. I thought “I should release this, someone might find it useful” and there I was on the slippery slope.
When I first dropped by the internal Sun Open Source Review page, my heart sank, and I snarled away in IM at Simon Phipps, saying “this thing is designed to discourage,” but he was gentle and open-minded, and I’ve decided that while the process isn’t perfect, it isn’t about discouraging you, it just wants you to prove that you’re serious. Given the number of OSS projects eagerly announced and then left to moulder on SourceForge or equivalent, I suspect this is probably a good thing.
My experience is specific to something that’s not going to become a Sun product and is going out with a vanilla OSS license (MIT in the Ape’s case; less is more). I expect the experience would be different for a product that we’re going to ship and support, which is entirely appropriate.
The process is all automated through a set of Web forms that are integrated with internal email; it even tracks how much time you’ve spent waiting for various levels of approval. It ain’t pretty but it seems to sort of work.
There are a bunch of steps. You have to get approval from your own management chain up to the nearest Vice-President. Along the way, you need sign-off from Brand Management, Trademark Legal, and International Trade Legal (export-control regulations are a cross big companies like Sun have to bear). Once that’s done, OSS Supremo Simon Phipps has to sign off, as well as our designated Open Source Legal Heavy. There’s a bunch of extra work if patent applications are involved, which fortunately I didn’t have to go near.
You have to provide a lot of information about your project, what it does, where it’ll live, why it’s worth doing, and so on. This seems fair to me.
The one that was the most work was the Trademark piece. You just can’t assert “I’ll call this Foobar” and publish the code; lots of good names are taken and if you work for a public company, you really don’t want to accidentally step on someone else’s trademark with your coolio project name because if you do, they’re gonna call their attorneys first thing.
I actually wanted the trademark people to check out both “Atom Protocol Exerciser” and “Ape”; they told me in the politest possible way that this costs real money and real time so would I please bloody well pick one; fair enough.
I reported a couple of what I consider bugs in the process, where you can end up waiting for approval without knowing who exactly you’re waiting for. On the other hand, when a couple of them stretched out, general complaints in the direction of That Department unjammed them pretty quick.
Checking out names takes time—a couple of weeks in my case—that’s just a fact of life. Aside from that, the process pretty well moved right along, occasionally requiring me to snarl politely at someone “Having a problem with my OSS application?”
In fact the Ape could have been approved for publication last September, only when it washed up on the nearest VP’s desk (that would be Laurie Tolson, my manager at the time) I was real busy with something else and forgot about it; I’m sure if I’d sent a one-line email along the lines of “Hey Laurie, can you approve my OSS release already?” she would have. As it happens, she cleared it before I got around to bugging her. That aside, the whole process would have taken about 21 days.
Seems about OK to me.
Comment feed for ongoing:
From: John Cowan (Mar 13 2007, at 07:57)
I'd say any claim by Sun to be the world's largest FLOSS software creator is pretty shaky. For one thing, there are only two mentions of the FSF in the MERIT report at all; one is definitional, and the other mentions that it contributed the most LOC to a full Debian distro -- nothing surprising there. It's completely omitted from the COCOMO cost model, being neither a firm nor a university.
That model is itself of doubtful relevance. It estimates that it would take Sun 51,372 person-months of programming effort to *completely recreate* its open-source software from scratch today, which is quite likely true but also quite unreal. For example, all the SVR4 code in OpenSolaris bears a Sun copyright notice, but much of it predates Sun's acquisition of it. Likewise, the price that Sun paid for StarOffice does not well represent the cost of producing that code; you buy companies at market value, not on a basis of their costs. So we see that identifying Sun's replacement cost with Sun's expenditure to produce or acquire the original code is seriously misleading.
[link]
From: David Carlton (Mar 13 2007, at 22:16)
The FSF was of course very important, but if you're talking expenditure to produce open source code, the FSF's is much much lower than Sun's. They never had more than a handful of employees; for at least a decade they (as far as I can tell) have contributed essentially no code directly. They had a seminal role, and continue to have a not unimportant role in accepting others' contributions, but I doubt the quantity of direct FSF labor would put them in the top 10.
[link]
From: John Cowan (Mar 13 2007, at 23:29)
But that's precisely the point: the COCOMO model does *not* reflect Sun's costs. Rather, it reflects how much Sun would have to pay to replace all of its OSS software at current market rates. If the same approach were applied to the FSF's contributions, the costs would be huge: how much would it cost just to replace gcc, lock stock and barrel?
[link]
From: David Carlton (Mar 14 2007, at 23:20)
I'm not going to argue that Sun's costs are portrayed accurately: I think you have a reasonable point there, though I'm not completely convined. (Also, I haven't read the original report, so I don't really know what its cost model was!) But I don't think it's the same as the FSF example, for two reasons:
For one, Sun buying a company and then open sourcing their work feels different to me from the FSF's owning the copyright to work that I (or Red Hat / Cygnus or CodeSourcery) did. In the Sun case, if they hadn't open sourced the work, it would still be closed source. In the FSF case, I (and presumably also Red Hat and others) would have happily contributed code even if the FSF weren't requiring copyright assignments. (Actually, maybe I would have contributed code more happily in that case...)
But even if you do want to consider those cases as parallel and throw them both out: I'm not sure the FSF has ever employed more than about 5 software engineers at any one time. And Sun has paid a lot more people than that to work on Solaris, Java, and other projects. (Of course, the report came out before the first bits of Java were open sourced.) So, if you only want to count direct labor, fine: I guarantee that Sun would come out far ahead of the FSF, and I'm willing to believe that it would come out ahead of anybody else, too.
(Needless to say, hours of labor is a very different thing from importance. And maybe I'm still misunderstanding?)
[link]
From: Brad Neuberg (Mar 16 2007, at 05:06)
Sun has indeed contributed a great amount of open source. I'm thankful for many of their tools.
However, the process for an individual within Sun to put out their own open source project you describe sounds really bureaucratic to me. I'm sure it's better than other places, but man it sounds intense. Never forget that you might have access to people at Sun because of your background that the average Sun engineer might not have -- will they be able to call up some of these people and have it expedited?
[link]
From: David Carlton (Mar 16 2007, at 17:16)
I went through an earlier version of Sun's open source process (before it was automated) for a small project I wanted to open-source (see http://unittest.red-bean.com/), and it really wasn't that bad. (I doubt I spent as much of a day of my work time, over the course of a month or so, on getting approvals.) And I don't have nearly the influence within Sun that Tim has. So I think it works pretty well, and doesn't depend on individuals with pull being able to expedite things: you have to be willing to put in a bit of effort, and wait for a little while, but not very much effort or very long. Not the thing you want to do for throwaway code, but reasonable enough for all but the most trivial of projects.
Incidentally, I've also been impressed by Simon Phipps, our open-source officer. Whenever I've had a question about anything open-source related within Sun, he's always been very quick to answer.
[link]