Where does the money come from?

by Greg Lehey grog@lemis.com

Two months ago I finished my article Wither BSD? with the question ``where does the money come from?'', with a promise to look into that issue in more detail this month. Since then, a number of things have happened:

• I realised that I was jumping to conclusions. Why make money out of Open Source? For a lot of people, it's a labour of love.

• Wes Peters wrote an article on the same topic last month.

• Most significantly, the company I was working for at the time, Linuxcare, got bought out by TurboLinux, and laid me off. Under the circumstances, I believe that laying me off was the correct decision: they had hired me to start BSD support, something that after 12 months had still not eventuated.

Especially as a result of the third point, you can be sure that I have spent a lot of time thinking about these issues. But let's look at the first one first.

Why should we make money?

Money isn't everything, of course. When the BSD projects started out nearly ten years ago, few people had any expectations that they would ever make money out of them. Bill Jolitz specifically didn't want to make money, to the extent that he had friction with BSDI as a result.

Nevertheless, the projects wouldn't have got as big as they have done if there had been no commercial factor. Indeed, the size of the respective projects, as well as of the Linux community, bears a direct relationship to the amount of commercial involvement. The trick is to have the commercial involvement without non-commercial participants losing their interest, and without the commercial companies abusing the others. I recently heard a representative of an open source company say ``Oh, we don't need to write that code. We'll find a hobbyist to do it''. This is clearly not in the spirit of the movement.

So, how about that money

That leaves us with the original question: how do you make money?

The Linux community has a basic problem with money: at a certain level, it considers it to be dirty. The GNU General Public License specifically excludes some ways of making money. You can't charge license fees for software which is based on GNU software, nor for your own software if you include it with GNU software:

But when you distribute the same sections as part of a whole which is a work based on the Program, the distribution of the whole must be on the terms of this License, whose permissions for other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it.

A whole ethic has grown up around the GPL, and for example it is generally considered incompatible with the GPL to include proprietary kernel code with the Linux kernel. We'll look at this again further down.

The real issue, though, isn't a license issue: it's a mentality issue. The GPL is sacred to a large number of people in the Linux industry, and as a result they have difficulty identifying with more traditional business people: a ``them'' and ``us'' situation develops.

It's fairly clear to see who loses in this situation: everybody involved does. The companies run into trouble because they either can't get experienced businessmen to work for them, or the experienced businessmen can't identify with the technical people. The technical people lose because the companies do badly. The customers lose because of the instability of the situation.

Who needs Open Source, anyway?

The biggest problem with Open Source software is that people can't make money with it. Companies must make money to survive. So why create Open Source software?

The answer depends on the situation. Let's look at a few:

• A company makes its living out of supporting software. In this situation, it may be a reasonable thing to do to write and give away software so it can be supported. This is my personal favourite, though some people point out that if you want to make money out of support, it's in your interest to write obfuscated and hard-to-use software.

• Another company might make its living supplying professional services to the software industry. In this case, it may be useful to write free software to support this effort. This depends on the client, however.

• Let's look at the other side of the previous example. Who's the client? If they're selling a pure software package, you can bet your bottom dollar that they won't want to make it free. Or at any rate, not all of it. That would be business suicide.

• At the other end of the scale, computer manufacturers are interested in Open Source to install on their products. Companies such as Dell and IBM offer machines with Linux preinstalled. They obviously don't have any worry about the fact that the software is free.

• A more typical client in this kind of situation is between the two previous ones: a company building an embedded product, for example network attached storage or intelligent routers. In this case, an open source base is a good idea, because that way they don't need to reinvent the wheel, and they can give the software away with no problems. Good examples are the Whistle Interjet and the Tivo intelligent VCR. The Interjet uses FreeBSD, the Tivo uses Linux.

This last category is interesting. How does Tivo reconcile its commercial interests with Linux? Well, yes, they will give you the source code of the Linux system upon which it's based, but not of their own extensions, which include a file system designed to store image data. How do they get away with that?

The GPL is unsuited to this kind of software. It requires that the software be free, but it's clear that things like Tivo would just never happen if all software were free. People found two solutions:

• The GNU project brought out the GNU Lesser General Public License, or LGPL originally called the GNU Library General Public License. As its name suggests, it was originally intended for libraries. The intention is that the library may be used in conjunction with proprietary software without requiring that that software be subject to the GPL.
• Somebody, possibly Linus Torvalds, decided that it's OK to load a proprietary kernel module in the Linux kernel. I don't agree with this distinction: in either case you're linking the code with the kernel, and the only difference is when you perform the link stage. This is how Tivo can legally include proprietary code in their system.

Do you get the feeling that there's a lot of wrangling going on here to reconcile the GPL with the facts of life? I do. With the BSD licence, none of this is necessary.

Getting back to the question of who needs Open Source, I think that we need to accept that not everything can be Open Source. A significant proportion of new development is performed by small startup companies: Whistle is an example. The startup has a new idea and implements it. Obviously the software is proprietary.

At a later date, though, one of two things has happened: the startup has gone broke, or the technological edge they had is no longer present. At this point, it no longer makes sense for the software to be proprietary, and it is in the interests of the company to release it as open source, because then other people will maintain it. This is how the RAID-5 code for Vinum was written: for the first 18 months, it was proprietary to Cybernet, after which it was released to the FreeBSD project.

That money again

Back to the question of making money. Why doesn't it work? As a commodity, Open Source has a lot of advantages. The BSD model is more compatible with the Real World than the GPL model, but the differences aren't significant. The real issue is that most of the open source companies just don't have the commercial background to be successful. Many of them have some really good ideas about how to make money, but without solid management they are unable to make money. Others have ideas that are less solid; for example, I can't understand how anybody can make money by producing a Linux distribution.

Of course, so far the most popular method of making money was to take advantage of a naive public and go public. The problem with this method is obvious: you can only make one IPO; what are you going to do for an encore?

Crystal ball gazing

So what will the future bring? I started the previous article by pointing out that freely available source code is not new. What's new is the attention it's getting in public, and that's at least partially due to the Microsoft trial issue. My guess is that in five years,

• not more than one of the current Linux companies will be in existence;

• mainstream computer manufacturers will have accepted that the departure from open source in the late 70s was a bad idea, and they will open source large quantities of their software;

• leading edge software will remain closed source.

Where does that put BSD? I don't know. People have been predicting the imminent death of UNIX for decades now, and it still looks as strong as ever. I'm sure it will still be around in five years time, and almost certainly in ten.

Your opinion, please

If you've been reading Wes' and my articles since they started, you'll notice that they have been getting shorter. We did some soul-searching about not delivering your money's worth, but then it occurred to me that maybe we have been being too long-winded in the past. We'd be very interested to hear your opinion about the length of the articles: are they too long, too short, or just right?