Social Architecture: The Importance of Contracts and Unlimited Property

A project that has a well-written contract defining the conditions for its completion will fall apart with a much lesser probability.

The importance of contracts

Let's discuss the controversial but important issue of which license to choose. I would highlight “BSD” along with MIT, X11, BSD, Apache and other similar licenses, and “GPL” with GPLv3, LGPLv3 and AGPLv3. The main difference is the distribution of rights to any version of the forks, which protects any organization from hijacking software, and thereby making it “free”.

Technically, a software license is not a contract because you are not signing anything. But in a broad sense, it is convenient to consider it a contract, because it implies the obligations of all parties and allows you to enforce them in court, in accordance with copyright.

You may ask, why do we need contracts when working with open source? After all, the main thing is goodwill, disinterested collaboration of people. Are you sure that the principle “better less is better” is always appropriate here? Doesn't that mean more rules - less freedom? We really need lawyers to tell us how we work together? It seems cynical and even counterproductive to enforce restrictions and rules in a happy open source community in the free software community.

But the real nature of man is far from so beautiful. We are actually neither angels nor devils, but simply self-serving winners, the last links of a single chain of winners of a billion years long. In business, heart affairs, or when working together, we either fight and argue, or leave them.

Look at this from the other side: teamwork has two extreme outcomes. Or failure, insignificant and useless, in which case any normal person will calmly leave. Or success, substantial and valuable, in which case we will begin the struggle for power, control and, often, for money.

A well-written contract just protects those valuable relationships from conflict. Marital relations are less likely to end in divorce if its conditions were clearly agreed upon in advance. A business enterprise in which the parties stipulate the solution of various typical conflicts, for example, when one side appropriates customers, or the material values ​​of the other side, is much less likely to end in contention.

Similarly, a software project that has a well-written contract defining the conditions for its completion is much less likely to fall apart.

An option seems to be with the absorption of the project by a larger organization, which, by fear of losing collateral and a brand, will be able to rally the team. From my own experience I know that this has its own price, and often it ends up gaining benefits from richer participants (who can sometimes afford huge expenses).

In an open source project or a free software project, disintegration usually takes the form of a fork, when a community is divided into two or more groups, each of which has its own vision of the future. During a honeymoon, which can last for years, the project is not afraid of a gap. But when the project starts to cost money, or when its main authors emotionally burn out, good faith and nobility disappear.

Therefore, when discussing software licenses, when it comes to your code or the code you use, a little cynicism will not hurt. Do not ask yourself: “which license will attract more followers?” Because The answer depends on the mission statement and participation process. Ask yourself: “if the project ends in battle and is divided into three parts, which license will save us?” Or: “if the entire team is bribed by a hostile company in order to appropriate a code for itself, what license will save us?”

Long survival requires persistence in difficult times, but allows you to enjoy good times.

When BSD projects branch, they cannot easily merge again. In fact, when a one-sided fork of a BSD project arises, the following systematically happens: The BSD code becomes part of a commercial project, that's what happens. When a fork of the GPL project happens, its merger is a common thing.

Let me give you the relevant story about the GPL. Although open source software communities were already widespread in the 1980s, they still used simple licenses that worked until the project began to raise real money. At that time, there was a solid Emacs text editor, originally built on Lisp by Richard Stallman. Another programmer, James Gosling (who later showed us Java), rewrote Emacs in C with help from accomplices, suggesting that it would be open. Stallman took this code as the basis for his C version. Gosling later sold the code to a company that took and blocked the opportunity for anyone to distribute a competing product. Stallman considered this sale of collaboration to be an extremely unethical act and began to develop a reusable license,

As a result, it resulted in the GNU General Public License, which used traditional copyright law to protect the possibility of material recycling (remixability). It was an elegant reception, which was adopted in other areas, for example, Creative Commons for photos and music. In 2007, version 3 of the license was released, which was a response to the belated attacks of Microsoft and others. It has turned into a long and complex document, but corporate copyright specialists are well acquainted with it, and in my memory very few companies dare to use the library software under the GPL license, provided that the boundaries are clearly marked.

Thus, a good contract - and I believe that the modern GPL is ideal for software - allows programmers to work together without prior agreement, organization or belief in decency and goodwill. Collaboration becomes cheaper, and conflicts turn into healthy competition. The GPL does not just determine what will happen to the fork, it encourages fork as a tool for experimentation and learning. Somewhere with a “more liberal" license, a fork can ruin a project, but GPL projects develop thanks to forks, because successful experiments can be back included, according to the contract, in the original product.

Yes, there are many thriving BSD projects and many dead GPL projects. Generalizing is always bad. The fate of the project depends on many reasons. However, in sports competitions it is worth using any advantages.

Another important feature of the confrontation between BSD and the GPL is the “leak” - I call it because it reminds me of the process of filling a container with a hole at the bottom, which is small but significant for the result.

Drink Me

Here is a story for you. It happened to the older brother-in-law of a cousin of a friend of my work colleague. His name was, and still, Patrick.

Patrick was a computer science specialist with a Ph.D. in network topologies. He spent two years and his savings creating a new product and chose the BSD license, as believed that she would bring him more recognition. He worked in his attic, infringing on himself in everything, and proudly published the work. People applauded, because the work was just fantastic, his email. the mail was buzzing with activity, patches and happy chatter. Many companies told him how many millions they saved using his work. Some even paid him for consultations and training. He was invited to speak at one conference after another, even collect badges with your name. He started his small business, hired a friend to work, began to dream of sky-high peaks.

But once someone showed him a new project, under the GPL, which was a fork of his work with some improvements. He was annoyed, upset, and kept asking how - open source friends! - how could they steal his code in such a shameless way. Then there was a lot of long discussion about whether it is legal to release its BSD code under the GPL. It turned out that yes. He tried to ignore the new project, but soon realized that new patches coming to him could no longer be merged with his own work!

Even worse: the GPL project began to gain popularity, and some of Patrick’s main followers began to make small and then more solid patches for him. And again, he could not use these additions, and then he felt abandoned. Patrick was depressed, his girlfriend left him for a currency broker, who, funny enough, is Patrice, and he stopped working on the project in general. He felt betrayed and miserable to tears. He fired his friend, who took it hard and then always spoke very unflattering about him (“closet banjo player”). As a result, Patrick got a job as a project manager in a cloud company and by the age of forty had completely stopped programming for fun.

Poor Patrick. I almost felt sorry for him. When I asked him: “Why didn’t you choose the GPL?”, He answered: “Because it is a limiting viral license.” “Let you have a doctorate and you are the elder brother-in-law of a cousin of a friend of my colleague at work, but you are an idiot, and Monica did the right thing to leave you. You published your work, inviting people to steal your code, and when people did just that, you were upset. To make matters worse, you acted hypocritically, because while they were doing it secretly, you were happy, but when they openly announced this, you felt, you see, abandoned. ”

To watch how your more cunning team seized your work and uses it against you is torture, so why allow such an opportunity? Any proprietary project that uses BSD code captures it. A public GPL fork may sound offensive, but you certainly won’t do it.

BSD is like a treat. I literally (metaphorically) hear the whisper “drink me”, in such a quiet voice that happens to speak to you a bottle of the best beer in the world - and this, without a doubt, is Orval, brewed by the ancient and almost disappeared order of silent Belgian monks Les Gars Labas Qui Fabrique l'Orval. The BSD license, like its close clone MIT / X11, was specifically designed by the university (University of California, Berkeley) to give out work or effort without selfish motives. It was a way to push subsidized developments at a price below cost, price dumping in order to enter the market. BSD is an excellent strategic decision, but only suitable for large, well-funded institutions that can afford to use the First method. The Apache license is the same BSD, only in a suit.

For us, small business captains who recount their funds as the last bullets, a leak of work or effort is not acceptable. It would be great to redraw the market, but we cannot afford to subsidize our competitors. The BSD network stack led to the emergence of Windows on the Internet. We cannot allow battles with those with whom we must be allies by nature. We cannot afford the mistakes of a fundamental business, because in the end we will have to fire people.

It all comes down to behavioral economics and game theory. The type of license that we choose affects the economies of those who use our work. There are friends, enemies, and food in the software industry. BSD puts us in the eyes of others with lunch. Closed code is the enemy (do you like paying people for programs?). However, the GPL, with the exception of Patrick, are allies. Any fork of ZeroMQ is licensed compatible with ZeroMQ, until the moment when we encourage forks as valuable tools for experimentation. Yes, it seems unusual to watch someone pick up a toy from you and tinker with it, but - you can take it back at any time.

Process

If you still agree with me - great! Now I will explain the process of building an open source community. Here's how we built or nurtured or sensitively introduced the ZeroMQ community into the world.

Your goal as a community leader is to motivate people to get there and explore, to convince them that it is safe for them and others, to reward them in case of successful discoveries and to guarantee them that they can share their knowledge with others (not because we ask them, and not because they are generous, but because this is the Law).

This is a repeating process. You make a small product, at your own expense, but in full view of everyone. Then you build a small community around the product. If you have a small but real hit, then the community will help to develop and build the next version, and it will become more.

And then this community will create the next version, etc. Obviously, in doing so, you remain part of the community, perhaps even its most important member, but the more control you want over material results, the less people will want to participate. Plan your resignation before someone decides that you are their next problem.

Madness, beauty and simplicity

You need a goal that is crazy and simple enough to get people out of bed in the morning. Your community must attract the best people, and this requires something special. In the case of ZeroMQ, we said that we were going to create “Fastest. Messaging. Always, ”and this is an example of a good motivator. If we said that we were going to make "an elegant transport level that will connect all the moving elements of your enterprise cheaply and flexibly", we would fail.

Also, your work should be excellent, useful here and now, and attract attention. Your members are users who want to know a little more than they know now. Make it simple, elegant and brutally clean. People should experience the emotions of using your labors. They must feel something, and if you carefully solved at least one big problem that they did not even realize before, they will be with you a small part of the soul.

Your work should be easy to understand, use and join. Too many projects are burdened with obstacles to join them: put yourself in the place of another person and see the reasons why he came to your site, thinking "hmm, an interesting project, but ...", and then left. You want them to stay and try, at least once. Use GitHub and put the task tracker there.

If you do all this right, your community will be smart, but more importantly, it will be intellectually and geographically diverse. This is really important. A group of like-minded experts will not be able to explore the terrain of the problem well. They tend to make big mistakes. Diversity always prevails over education.

Stranger, let me introduce you to the Stranger

How often do two people have to coordinate their actions when working together? In most organizations, very often. But you can reduce this need to zero, and then people can work without even meeting in person, without taking part in a teleconference, on a business trip, without discussing Roles and Responsibilities, surrounded by an obscene large pile of bottles of cheap Korean rice wine.

You will need well-written rules developed by someone cynical, like me, to encourage strangers to work together for mutual benefit rather than conflict. The GPL will be a good start. GitHub and its fork merger strategy will be a good continuation. And then you need something like our C4 rule book to control how the work actually works.

C4, and I use it now for every new open source project, contains detailed and verified answers to most of the common mistakes people make: for example, such a sin as working offline in a secluded place with others "because it's faster." Transparency is key to building trust, without which in turn there will be no scale. Let every change be in sight just like the whole process, and then you can fully trust the results.

Another mortal sin that many open source developers fall into is the belief that they are superior to the rest. "I founded this project, in addition, my level of intelligence is higher than that of others." This is not only not modest and rude, and often not true, it is still bad for business. The rules should apply to all equally, without distinction. You are part of the community. Your job as the founder of the project is not to impose your vision of the product on others, but to establish good, honest and enforced rules.

Unlimited property

One of the most unfortunate inventions of the knowledge industry is that ideas are property. This medieval bullshit should be buried in the wake of slavery, but it still brings too much money to too many powerful people.

Ideas are cheap. But what is property is the hard work we do to create the market. “As I drowned, I dug” is the right model for inspiring people to hard work. Be it moral authority in the project, money for consultations, sale of the trademark of a rich and large company: if you did this, you own it. But in fact, your main asset that determines your potential is “attendance,” the participants in your project.

This will require an unlimited amount of free space. Fortunately, GitHub solved this problem for us, so on my deathbed I will be grateful to him (in life there are too many things, for which I am grateful, and there is nothing to list here, because we only have one hundred pages or so but this is one of those things).

You cannot scale a single project with many owners the way you could scale several small projects, each with fewer owners. When we accept forks, a person can become an “owner” by clicking once. And then he only needs to convince the others to join, showing them their unique value.

Therefore, in ZeroMQ we tried to facilitate the process of writing binders on top of the root library, and we stopped trying to do them ourselves. This made it possible for others to do this, to become their owners and to credit it to themselves.

Translation of the book “Social Architecture”:

• Foreword The wisdom of the crowd
• Chapter 1. Toolkit
• Chapter 2
  - Emotional burnout of volunteers
  - How to capture / protect an open-source project
  - The myth of individual intelligence
• Chapter 3
  - ZeroMQ Community
  - Software Architecture Psychology
  - The Importance of Contracts
• Chapter 6. Living Systems

---