Daily Archives: November 28, 2006

A short course in open-source and corporate communications

Here’s a short course on the lessons I’ve learned from my involvement in several major corporate announcements about open-source.

Don’t underestimate the communication folks. Their job is to explain technology, strategy and your company to the public. The good ones are very good at it. Don’t think your detailed knowledge of the technology gives you an edge, or that many folks really care that much about the technology. The announce is trying to paint a big picture, so you don’t want to get mired in detail.

These announcements are directed to reporters for major newspapers, industry-related web sites and industry analysts. Corporate communications folks are very good at this.

Thing is, open-source developers don’t follow the industry via these channels — they are too busy coding, reading e-mail and chatting on IRC. (Does anyone think Linus stays up at night worrying about Linux’s position in the Gartner Magic Quadrant?)

They key point is that to the open-source community it doesn’t really matter what you do say and long as you DO NOT SAY certain things.

However, word will quickly get around if you slip up, as the community is very good at smelling a rat, so here are the things you don’t want to say:

  • Anything that implies you seek to maintain control. You can’t allow even the perception that you still believe you own the code. It belongs to the community now, not to you. Things to avoid include such statements as:
    • Our developers look forward to directing the community to implement some of the good ideas they have come up with but haven’t yet had time to do.
    • We are still working on the governance model.
    • Our long experience in this area will now allow us to exert an even greater leadership position by working with the open-source community
  • Any attacks on competitors or other open-source projects. The purpose of the announce is to say what you hope to accomplish, not to attack others. It’s your party, so use it to your advantage. Things to avoid include:
    • With this announcement we hope to provide a more viable alternative to xxx
    • While name-that-competitor has only done this-or-that, we are now ready to do much better …
  • Self-aggrandizement and patting yourself on the back, especially the genre of locker-room phrases such as “my ?? is bigger than your ?? . Things to avoid here include:
    • This is the largest open-source contribution in … Avoid phrases such as “last decade” or “in the history of open-source” or “the history of the universe.” It’s not your code anymore, so who cares?
    • We continue by this contribution to demonstrate our leadership in the open-source arena …
  • Over-promotion of the code. It’s not your code anymore, it belongs to the community. Let them do the puffery going forth. Things to avoid include
    • This is the best damn … our company has even produced
    • This code is far superior to any other code in this area, especially that from …

If you can, try to arrange to have some real open-source folks around. It also helps if your own open-source folks can spread the word within the community.

Brother, can you spare a dime?

It’s tough being a blogger and open-source developer. As a blogger you labor in obscurity. As an open-source developer you probably labor in penury. Even worse, attempts to escape penury may expose you to calumny.

See for example, the words of the master of the flurry of fury, Dr. Marc Fleury, from
Another 15 years of Java: JBoss’ Fleury on the GPL, IBM, patents and Microsoft:

He was less generous about Sun’s critics. “IBM reacted negatively to the Sun announcement because IBM’s approach to open source is what we call ‘strip mining’, which is to let the open source community do things – then IBM comes and packages them, and adds proprietary code, and markets the result – witness WebSphere – so they have this dual strategy of proprietary products and low-end open source,” he said. This kind of strategy “usually works well with BSD style licenses where you can create, as a vendor, a competing offering that is proprietary.”

Dr. Fleury is not alone in thinking there is something wrong about making money using open-source. I noted similar sentiments voiced during the recent announce of the Sun/FSF alliance, endorsing the use of the gpl license because it wouldn’t allow corporations to “fork” the code and create commercial derivatives. This is a misunderstanding of the term “fork,” but that a topic best left to a future post.

As those active in the open-source arena know, there are two broad camps: the “free software” folks and the “open-source” folks. I’m in the latter camp, and so take my instructions from the Open Source Initiative (OSI). OSI is dedicated to managing and proposing the Open Source Definition (OSD).

The OSD lists ten criteria that must be met for a license to qualify as an open-source license. Here’s the sixth:

6. No Discrimination Against Fields of Endeavor

The license must not restrict anyone from making use of the program in a specific field of endeavor. For example, it may not restrict the program from being used in a business, or from being used for genetic research.

Rationale: The major intention of this clause is to prohibit license traps that prevent open source from being used commercially. We want commercial users to join our community, not feel excluded from it.

The OSI has no objection to using open-source code in commercial offerings. For example, the Apache License explicitly allows corporations, or anyone else for that matter, to use their code and modify it without imposing any requirement that the modifications must be made public.

IBM is not alone is using open-source code in this fashion. Other companies do it as well, including Dr. Fleury’s new employer, Red Hat.

As does MySQL.com, which licenses their code under both the GPL and a commercial license. Indeed they can be viewed as a commercial entity that uses the freely-available GPL-licensed version as a come-on to encourage customers to acquire the commercial version.

But, irony of ironies, Dr. Fleury should be the last to argue that it’s wrong to make money off open-source. After all he has made oodles of boodle by selling his open-source based company to Red Hat. He probably even made enough so he can afford a comfortable upper-middle class lifestyle.

Other companies strive both to make a profit and support open-source. A good example is Collab.net’s funding of much of the development cost of Subversion.

But if Dr. Fleury is that troubled by making money off of open-source, he might want to unload some of his oodles of boodle. Since so many open-source developers labor in penury, and some including myself find this topic depressing, perhaps we can find some solace from some Songs of the Great Depression


“Brother, Can You Spare a Dime,” lyrics by Yip Harburg, music by Jay Gorney (1931) (with “railroad” replaced by “package,” as in open-source package)

They used to tell me I was building a dream, and so I followed the mob,
When there was earth to plow, or guns to bear, I was always there right on the job.
They used to tell me I was building a dream, with peace and glory ahead,
Why should I be standing in line, just waiting for bread?

Once I built a railroad package, I made it run, made it race against time.
Once I built a railroad package; now it’s done. Brother, can you spare a dime?
Once I built a tower, up to the sun, brick, and rivet, and lime;
Once I built a tower, now it’s done. Brother, can you spare a dime?

Rudy Vallee
“Life is Just a Bowl of Cherries,” lyrics by Lew Brown, music by Ray Henderson (1931)

People are queer, they’re always crowing, scrambling and rushing about;
Why don’t they stop someday, address themselves this way?
Why are we here? Where are we going? It’s time that we found out.
We’re not here to stay; we’re on a short holiday.

Life is just a bowl of cherries.
Don’t take it serious; it’s too mysterious.
You work, you save, you worry so,
But you can’t take your dough when you go, go, go.

So keep repeating it’s the berries,
The strongest oak must fall,

The sweet things in life, to you were just loaned
So how can you lose what you’ve never owned?

Life is just a bowl of cherries,
So live and laugh at it all.

Ginger Rogers
“We’re in the Money,” lyrics by Al Dubin, music by Harry Warren (from the film Gold Diggers of 1933, 1933)

We’re in the money, we’re in the money;
We’ve got a lot of what it takes to get along!
We’re in the money, that sky is sunny,
Old Man Depression you are through, you done us wrong.

We never see a headline about breadlines today.
And when we see the landlord we can look that guy right in the eye

We’re in the money, come on, my honey,
Let’s lend it, spend it, send it rolling along!

Oh, yes we’re in the money, you bet we’re in the money,
We’ve got a lot of what it takes to get along!
Let’s go we’re in the money, Look up the skies are sunny,
Old Man Depression you are through, you done us wrong.

We never see a headline about breadlines today.
And when we see the landlord we can look that guy right in the eye

We’re in the money, come on, my honey,
Let’s lend it, spend it, send it rolling along!


How about it, Brother Fleury? I am not seeking any of your oodles of boodle — I have enough dimes so I can both put food on the table and also work on the Open Source Volunteers project on my own time, so I suggest you might want to consider sending some of your money “rolling along” to the good folks at the Apache Software Foundation?

What if? What not? On the importance of community

In a previous post, Make or buy? Home, sweet home — on the web, I argued that the most important decision facing a corporation considering starting a major open-source project is whether to build a community from scratch or buy into an existing community.

Sometimes there is no choice since there is no suitable existing community.

But if there is a suitable existing community then I think it is better to join that community than to build a new one from scratch.

That to me is the most surprising aspect of the SUN/FSF alliance and the recent announcement of the release of Java in open-source form under gplv2.

Why didn’t Sun leverage the existing Apache and Eclipse communities?

Now of course this was Sun’s decision to make, so I’m offering these thoughts here just to shed some insight on the various options that come into play when making this sort of choice.

But I expect the following announcement would have had a greater impact, and would have made a favorable outcome more likely.

In simple language, why didn’t Sun announce the following:

We’ve been working on Java for almost 15 years, and have been considering making Java more open for at least half of them. [1]

We have decided to make Java open-source. We seek to make it available to the widest possible audience, under a license compatible with existing open-source efforts around Java.

Accordingly, we are handing it over lock, stock and barrel to the Apache Software Foundation (ASF).

We look forward to working with the ASF to make Java a truly open platform.

Notes.

1. Sun made some noises about offering Java for ECMA standardization in late 1999. I decided to no longer work on Java when this fell though, believing then that Sun would make no meaningful effort towards making Java more open for the forseeable future.

Make or buy? Home, sweet home — on the web

Suppose you work for corporation that has on hand code that for strategic reasons it wants to release in open-source form, and you are asked to provide some guidance.

Here are your options:

  • 1. Make. Make the community from scratch, providing all the resources to establish the project web site, market the project, attract developers, establish a release model, convince people of your good intentions, convince people you will follow the open-source rules, and so on, and so on.
  • 2. Buy. Buy into an existing community, turning the code over to them and providing your developers not as project managers but as assistants to the managers of the existing community.

I’m a strong believer in the second approach. You want to buy into an existing community, the best such community you can find. You want to leverage that community to establish your project.

I say this because I’ve been there, and done that. Let me tell you about it, the story of Cloudscape/Derby.

Go to your favorite search engine and search for “apache database”. Within seconds you will see the word “Derby.” I like being able to say this — I spent almost four months of my life spending every spare moment I could to help make it happen.

One day in early April of 2004, as I stepped off the elevator on the way to my office a colleague said to me, “Have you heard the news about Cloudscape?”

I said no. However, I had heard about Cloudscape (CS, which I’ll use hereafter as that’s what I used for months in e-mails, in part to disguise the project’s purpose) before. In early 1999 I was invited to discuss Jikes at a Java user’s group meeting in NYC. One of the speakers who went before me was from a start-up called CS. Their product, CS, was a browser plugin written in Java. In those days before the arrival of the high-speed internet the page update time was significant, and CS was created to speed up the manipulation and analysis of data, as follows.

Data manipulation and analysis was done on the client machine by first downloading the data from the web and saving it into cached memory. The CS software was a relational database system that allowed the full use of SQL to retrieve data as well as various graphical tools to display the results. This greatly speeded up analysis.

I thought it a clever idea when I first heard it, and their demo looked promising, though I lost track of CS as I was involved so much in Jikes in those days. (CS is the only presentation I remember from that meeting though several other products were demonstrated.)

I learned a few hours later that my colleague was right. I got an e-mail from the CS team saying they had been told to open-source the code and so wanted some guidance on how to navigate IBM’s open-source process.

I soon learned from the team that the CS startup had been acquired by Informix and that the CS code had come to IBM when IBM acquired Informix. CS had matured into a high-quality piece of code — a “relational database in a Java jar file” was the simplest summary. If you added that jar file to your Java classpath, then you had full access to a relational database that had a full implementation of SQL and also met the ACID-test.

CS had once been a separate product, and had also once been the reference implementation for the corresponding Java database spec. Though it was no longer marketed separately, it was now one of the most widely-used components in IBM software, and was embedded in scores of IBM’s products. It was production-level code, the real deal.

The initial plan of the team was to start a new entity, perhaps based on the eclipse model. Let’s call that approach CS.ORG. The team felt this would allow them to build a community gradually, perhaps even shape the pace of development, develop tie-ins with IBM’s products as the code became more accepted, and so on.

It was a real opportunity — great code that filled a gap that hadn’t yet been met, that of a relational database in a jar file, as well as skilled developers on hand to show the community how the code worked. There were also backing from management, and so on.

Everything was coming up roses. It was just a matter of execution.

But there was a problem, a big problem. The code was big, very big.

There were almost a million lines of code in Cloudscape. Though perhaps medium-sized in terms of corporate applications, this is a large number in the open-source world. [1]

When we published Jikes it was just under 90,000 lines of C++. It took two programmers three years, or six programmer/years, to put that code together, at a cost to IBM of at least $1.5M. [2] That works out to about $100/line.

I did a study of the size of open-source packages back in the Jikes days. There were very few packages over 100,000 lines. This seems reasonable It takes at least a few thousand lines of infrastructure for almost any meaningful program, and when you add code that actually does something, you find that most open-source packages are in the range of 10-30 thousand lines. With two programmers you can make it up near a hundred thousand lines or so, though the way in which open-source packages are organized favors componentization.

These estimates are for C or C++. Java programs tend to be larger; for example, there are more statements needed to manage namespaces, and there is a requirement that each class must have its own file.

Suffice it to say that most open-source developers — save those who have spent quite some time working on the Linux kernel — have no experience working with code bases of a million lines or so.This meant that the plan of the team to slowly build a community while IBM retained clear control, hoping that developers willing to take on a million-line code base would come forth, was a dream, most likely a pipe dream.

I also felt that while CS.ORG might seem a good place to start, one should look ahead to the end-game. Where would you most like to be after three to five years?

I don’t know about you, but I’d like to have my code be part of the Apache Software Foundation (ASF) . Only the kernel folks have the same level of credibility. And, as with the kernel folks, everyone knows there will be a strong team in place to watch over that code for years — and more likely decades –to come. Torvalds and Behlendorf are in their mid-30’s now. Does anyone doubt that the work they started in their twenties won’t be around when they retire? (And I’m assuming they will continue working until they are at least 60, as they are not in this for the money, but for the love of the game.)

So within a few days I started sending e-mails and making calls, suggesting that IBM’s best approach would be to hand the code over to ASF.

What made this hard was that I knew IBM couldn’t just make a token donation, but that we would have to hand over the code lock, stock and barrel, making clear we were entrusting the code to Apache’s capable hands going forward, and that while we would be around to help as they deemed fit, we fully appreciated that from the get-go the code would be theirs, and no longer ours.

In my experience this is the most important part of transferring technology from its creators to another group, whether from a research lab to a development group, or from one part of a company to another part, or from a corporation to the open-source world:

To maintain any control at all you must give up all control.

The transfer can succeed only if all accept and understand that the ownership of the code has changed, and that the creators no longer direct the effort, but are now available only to advise and help, as requested.

I was not the only one to argue that giving the code to ASF was the best course. Others also felt the same, including folks with a lot more clout than me. I’m presenting the arguments I made and I can’t claim these arguments were decisive, but I do hope they provide some insight.

In any event, the decision to release via ASF was reached in early July, and the contribution to ASF was was publicly announced at LinuxWorld in early August.

However, there is one contribution I can take credit for. I also suggested that to improve the odds IBM should find someone with open-source experience who could serve as an ombudsman or trusted intermediary. Or as I put it:

We need a sheriff, someone trusted on both sides of the firewall. Our developers our good, but they are inexperienced in open-source, so there may be some mistakes, and we need someone on hand who can sort out the mess.

That’s how Ken Coar got his current job.

The rest is history.

For example, it was Ken who came up with the name change from Cloudscape to Derby. I remember some fun instant-message sessions during which he mentioned some of the names he was considering. It was his call to make, but as an Apache person (he is on the ASF board) and not as an IBM person (the IBMers wanted to retain the name, as I recall.)

Note that the key decision was not what license to use, but how to build a community. Once you know that then the choice of a license is a tactical decision. For example, with ASF we had to use the Apache license.

Notes.

1. IBM’s public statements said the code was worth about $70M. I was told it the code was about a million lines. I recall doing a count and finding from 800-1000 kloc. I did a download of Derby just now and found fewer lines, though I can’t say I counted them all correctly. Suffice it to say the code was indeed big by open-source standards.

2. The programmers both had Ph.D.’s in computer science, though not everyone would consider that an advantage.

However you count it, Philippe and I can jointly say we convinced IBM to invest at least $2M or so into open-source by funding our work on Jikes. We are grateful for their trust.

  • Pages

  • November 2006
    M T W T F S S
     12345
    6789101112
    13141516171819
    20212223242526
    27282930  
  • RSS The Wayward Word Press

  • Recent Comments

    daveshields on SPITBOL for OSX is now av…
    Russ Urquhart on SPITBOL for OSX is now av…
    Sahana’s Respo… on A brief history of Sahana by S…
    Sahana’s Respo… on A brief history of Sahana by S…
    James Murray on On being the maintainer, sole…
  • Archives

  • Blog Stats

  • Top Posts

  • Top Rated

  • Recent Posts

  • Archives

  • Top Rated