pieterh wrote on 18 Sep 2012 11:02

There are, it has been said, two ways to make really large-scale software. Option One is to throw massive amounts of money and problems at empires of smart people, and hope that what emerges is not yet another career killer. If you're very lucky, and are building on lots of experience, and have kept your teams solid, and are not aiming for technical brilliance, and are furthermore incredibly lucky, it works.

But gambling with hundreds of millions of others' money isn't for everyone. For the rest of us who want to build large-scale software, there's Option Two, which is open source, and more specifically, free software. You may be asking how the choice of software license is relevant to the scale of the software you build. It's the right question.

The brilliant and visionary Eben Moglen once said, roughly, that a free software license is the contract on which a community builds. When I heard this, about ten years ago, the idea came to me, can we deliberately grow free software communities?

Ten years later, the answer is "yes", and there is almost a science to it. I say "almost" because we don't have much evidence of people doing this deliberately with a documented, reproducible process. It is what I'm trying to do with Social Architecture. My pilot experiment was ZeroMQ, after Wikidot, after Digistan and the FFII. There were… a lot of pilot projects. Anyhow, it seems clear that any explanation of how to build software at scale (which, experience tells us, is where the Money (with a capital M) is) must discuss how to build free software communities.

The Game

Software is my business: I code to eat, and to feed my kids and to make sure my wife doesn't leave me for someone nicer and better looking. Of course I love coding and that sensation of sculpting perfect functionality out of the raw mass of possibility. But the world doesn't care how passionately we feel. We wrest our living from a market that is largely uninterested, and often hostile when it does notice. This is the Game, and the full strategy of how to win it is for a full book.

What I will say here is that you have to identify and destroy your competitors, that you have to develop active strategies, learn rapidly, move quickly, and in general appreciate the Game as a constant competition in which every participant is an ally, an enemy, or the ground over which you are fighting.

How seriously you take the Game is up to you, but keep in mind that my advice for the rest of this article is aimed at helping you win, if and when you play it.

The Contract

When I write my best-selling book, "How to Make Big $$$ From Open Source", the first sentence will be "Use the GPL."

Here is a true story, it happened to the eldest brother-in-law of the cousin of a friend of mine's colleague at work. His name was, and still is, Patrick.

Patrick was a computer scientist, with a PhD in advanced network topologies. He spent two years and his savings building a new product, and choose the BSD license because he believed that would get him more adoption. He worked in his attic, at great personal cost, and proudly published his work. People applauded, for it was truly fantastic, and his mailing lists were soon abuzz with activity and patches and happy chatter. Many companies told him how they were saving millions using his work. Some of them even paid him for consultancy and training. He got invited to speak at conferences. He started a small business, hired a friend to work with him, and dreamed of making it big.

Then one day, someone pointed him to a new project, GPL licensed, which had forked his work and was improving on it. He was irritated and upset, and asked how people — fellow open sourcers, no less! — would so shamelessly steal his code. There were long arguments on the list about whether it was even legal to relicense their BSD code as GPL code. Turned out, it was. He tried to ignore the new project but then he soon realized that new patches coming from that project couldn't even be merged back into his work!

Worse, the GPL project got popular and some of his core contributors made first small, and then larger patches to it. Again, he couldn't use those changes, and he felt abandoned. Patrick went into a depression, his girlfriend left him for an international currency dealer called, weirdly, Patrice, and he stopped all work on the project. He felt betrayed, and utterly miserable. Finally he took a job as an architect for a cloud company, and by the age of forty, he had stopped programming even for fun.

Poor Patrick, I almost felt sorry for him. Then I asked him, "why didn't you choose the GPL?" "Because it's a restrictive viral license", he replied. I told him, you may have a PhD, and you may be the eldest brother-in-law of the cousin of a friend of my colleague, but you are an idiot and Monique was smart to leave you. You published your work saying, "please steal my code as long as you keep this 'please steal my code' statement in the resulting work", and when people did exactly that, you got upset. Worse, you were a hypocrite because when they did it in secret, you were happy, but when they did it openly, you got upset.

Seeing your hard work captured by a smarter team and then used against you is enormously painful, so why even make that possible? Every proprietary project that uses BSD code is capturing it. A public GPL fork is perhaps more humiliating, but it's totally, utterly self-inflicted.

BSD says "eat me". It was designed specifically by a university (Berkeley) with no profit motive, to leak work and effort. It is a way to push subsidized technology at below its cost price, a dumping of under-priced code in the hope that it will break the market for others. BSD is an excellent tool in the Game, but only if you're a large well-funded institution that can afford to use Option One.

For the rest of us, small businesses who aim our investments like precious bullets, leaking work and effort is unacceptable. We cannot afford to subsidize our market. We cannot afford battles with those we should naturally be allies with. We cannot afford to make fundamental business errors because in the end, that means we have to fire people.

It comes down to behavioral economics and game theory. The license we choose modifies the economics of those who use our work. In the Game there are allies, enemies, and lunch. BSD makes most people see us as lunch. Closed source makes most people see us as enemies (do you like paying people for software?) GPL, however, makes most people, with the exception of the Patricks of the world, our allies. Any fork of 0MQ is license compatible with 0MQ, to the point where we encourage forks as a valuable tool for experimentation.

The Process

If you've accepted my thesis up to now, great! You may actually get rich from your free software products. Now, I'll explain the rough process by which we actually build an open source community.

You recall the simplicity-oriented design process, where I claimed that we build successfully accurate software by successfully exploring the problem landscape, rather than by sheer intellectual effort. Keep this in mind. Now, see your community as a group exploring that landscape and sharing the results of their work.

Your goal as leader of a community is to motivate people to get out there and explore; to ensure they can do so safely and without disturbing others; to reward them when they make successful discoveries; and to ensure they share their knowledge with everyone else.

It is an iterative process. You make a small product, at your own cost, but in public view. You then build a small community around that product. If you have a small but real hit, the community then helps design and build the next version, and grows larger. And then that community builds the next version, and so on. It's evident that the more control you try to assert over the material results, the less people will want to participate.

Crazy, Beautiful, and Easy

You need a goal that's crazy and simple enough to get people out of bed in the morning. Your community has to attract the very best people and that demands something special. With 0MQ, we said we were going to make "the Fastest. Messaging. Ever.", which qualifies as a good motivator. If we'd said, we're going to make "a smart transport layer that'll connect your moving pieces cheaply and flexibly across your enterprise", we'd have failed.

Then your work must be beautiful, immediately useful and attractive. Your contributors are users who want to explore just a little beyond where they are now. Make it simple, elegant, brutally clean. SOD it, and I mean that. The experience when people run or use your work should be an emotional one. They should feel something, and if you accurately solved even just one big problem that until then they didn't quite realize they faced, you'll have a small part of their soul.

And then, easy to understand, use, and join. Too many projects have barriers to access: put yourself in the other person's mind and see all the reasons they come to your site, thinking "Uhm, interesting project, but…" and then leave. You want them to stay, try it, just once. Use github and put the issue tracker right there.

If you do these things well, your community will be smart but more importantly, will be intellectually and geographically diverse. This is really important. A group of like-minded experts cannot explore the problem landscape well. They tend to make big mistakes. Diversity beats education any time.

Stranger, meet Stranger

How much up-front agreement do two people need to work together on something? In most organizations, a lot. But you can bring this cost down to zero, and then people can collaborate without having ever met, done a phone conference, meeting, or business trip to discuss Roles and Responsibilities.

You need well-written rules that are designed by cynical people like me to force strangers into mutually beneficial collaboration instead of conflict. The GPL is a good start. Github and its fork/merge strategy is a good follow-up. And then you want something like our C4 rulebook to control how work actually happens.

C4 (which I now use for every new open source project) has detailed (and tested) answers to a lot of common mistakes people make. For example, the sin of working off-line in a corner with others "because it's faster". Transparency is essential to get trust, which is essential to get scale. By forcing every single change through a single transparent process, you build real trust in the results.

Another cardinal sin that many open source developers make is to place themselves above others. "I founded this project thus my intellect is superior to that of others". It's not just immodest and rude, and usually inaccurate, it's also poor business. The rules must apply equally to everyone, without distinction. You are part of the community. Your job, as founder of a project, is not to impose your vision of the product over others, but to make sure the rules are good, honest, and enforced.

Infinite Property

One of the saddest myths of the knowledge business is that ideas are a sensible form of property. It's medieval nonsense that should have been junked along with slavery, but sadly it's still making too many powerful people too much money.

Ideas are cheap. What does work sensibly as property is the hard work we do in building a market. "You eat what you kill" is the right model for encouraging people to work hard. Whether it's moral authority over a project, money from consulting, or the sale of a trademark to some large, rich firm: if you make it, you own it. But what you really own is "footfall", participants in your project, which ultimately defines your power in the Game.

To do this requires infinite free space. Thankfully, github solved this problem for us, for which I will die a grateful person (there are many reasons to be grateful in life, but this is one of them).

You cannot scale a single project with many owners like you can scale a collection of many small projects, each with fewer owners. When we embrace forks, a person can become an "owner" with a single click. Now they just have to convince others to join, by demonstrating their unique value.

So in 0MQ we aimed to make it easy to write bindings on top of the core library, and we stopped trying to make those bindings ourselves. This created space for others to make those, become their owners, get that credit.

Making Money from Open Source

Now, finally, how to make money from your successful open source project. Start by realizing that it will take years to get to the point where you can make real money. Patience, an economical lifestyle, and no debts are as important as anything else.

To make money from your open source, you must ensure your competitors stay or become marginal. That is fairly straight-forward: find their weaknesses, attack those, protect or hide your own weaknesses, repeat until it's over. If you don't think this is an ethical way to do business, just wait a few years. You will either learn, or become an employee . By using the GPL we should already have converted most compatible projects into allies, so it's fair to say the GPL is pacifist as well as ultra-capitalist.

Then, you must brand your product. The branding is key to explaining to people why they will send you real money (instead of emails asking you to do their homework). Choose a bold, confident logo and name, and website, and focus your brand on your core values, which are "crazy, beautiful, easy".

Now, what can you sell? Forget about "commercial licenses". Part of your deal with your growing community of contributors was that you would never fork their work to compete against them. This means no copyright assignments, and every patch owned by its author.

How about commercial add-ons? Perhaps, but in my experience you will always benefit more from building more open source.

So, this leaves two or three options. One is to sell your services helping others use the technology. The nice thing is you can scale this rapidly. After all, you have a community of ready-trained experts to call on, right? Who better to hire than the guy who just spent a month learning the source code.

The second option is to sell your business, for which you have to plan well in advance. What you in fact sell then isn't the copyrights, since you don't own these fully (or even in majority). It's the trademark, reputation, and the goodwill of the community. The new owner may make a mess of things. In that case you, or anyone else, can fork the whole thing right back to where it was.

Depending on the type of product you're making, there will be other services to sell. Support agreements ("pay us X per year and we'll fix any issues you hit within X hours or days") are an easy sell to larger customers. Advertisements can be profitable if you run very large websites. You may find lecture tours and workshops good income.

Finally, and here's the real money maker: t-shirts with pictures of cats saying funny things about your software. "I UZES 0MQ TO GETS MAI CHEEZEBURGERS" is our most popular one these days.