Social Architecture: The Importance of Contracts and Unlimited Property

A project that has a well-written contract that defines the conditions for its completion will fall apart with much less likelihood.

Importance of Contracts

Let's discuss the controversial, but important question of which license to choose. I would single out “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 forks, which protects any organization from software capture, and thus making it "free".

Technically, a software license is not a contract, because you do not sign anything. But in a broad sense, it is convenient to consider it a contract, since it implies the obligations of all parties and allows forcing them to be executed in court, in accordance with copyright law.

You may ask, why do we even need contracts when working with open source? After all, the main benevolence, disinterested joint work of people. Are you sure that the principle “better less yes better” is always appropriate here? Doesn't that mean more rules mean less freedom? We really need lawyers to tell us how to 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 not so beautiful. We are in fact neither angels nor devils, but simply self-serving winners, the last links of a single chain of winners a billion years long. In business, in heart affairs, or when working together, we either fight and argue, or we leave them.

Look at it from the other side: working together has two extreme outcomes. Or failure, insignificant and useless, in the case of which any normal person will quietly leave. Or success, substantial and valuable, in which case we will start 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 stipulated in advance. A business enterprise in which the parties negotiate the solution of various typical conflicts, for example, when one side assigns customers or the material values ​​of the other side, is much less likely to end in discord.

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

An alternative seems to be the option of absorbing a project by a larger organization, which, by fear of losing the provision and the brand, can rally the team. From my own experience, I know that it has its price, and often it ends in obtaining the benefits of richer participants (who can sometimes afford huge costs).

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 the honeymoon, which can last for years, the project is not afraid of a gap. But when a project starts to cost money, or when its main authors emotionally fade, conscientiousness 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 the question: “which license will attract more followers?” Because The answer depends on the mission statement and the participatory process. Ask yourself: “if the project ends in battle and is divided into three parts, which license will save us?”. Or: “if a hostile firm buys the whole team in order to assign itself a code, which license will save us?”

Long-term survival requires being persistent in difficult times, but allows you to enjoy good times.

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

Let me give you a relevant story about the GPL. Although the open source programming community was already widespread in the 1980s, they still used simple licenses that worked until the project started attracting real money. At the time, Emacs was a solid text editor, originally built on Lisp by Richard Stallman. Another programmer, James Gosling (who later revealed to us Java) rewrote Emacs to C with the help of accomplices, assuming that it will 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 possibility for anyone to distribute a competing product. Stallman considered this sale of teamwork an extremely unethical act and began to develop a reusable license that would protect the community from such.

In the end, this resulted in the GNU General Public License (GNU General Public License), which used traditional copyright law to protect the possibility of re-processing of the material (remixability). It was an elegant device that was adopted in other areas, such as Creative Commons for photos and music. In 2007, version 3 of the license was released, which was a response to late attacks by Microsoft and others. It has become a long and complex document, but corporate copyright specialists are well acquainted with it, and in my memory very few companies dare to use library software licensed under the GPL, provided that the boundaries are clearly marked.

Thus, a good contract - and I believe that the current GPL is ideal for software - allows programmers to work together without prior agreements, organizations or beliefs in honesty and goodwill. Cooperating becomes cheaper, and conflicts turn into healthy competition. The GPL does not just define what happens with the fork, it encourages fork as a tool for experimentation and learning. Somewhere with a “more liberal” license, forks can destroy a project, but GPL-projects are developed thanks to forks, because successful experiments can be included back, according to the contract, in the original product.

Yes, there are many thriving BSD projects and many dead GPL projects. Summarize is always bad. The fate of the project depends on many reasons. However, in sports competitions should use any advantage.

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

Drink Me

Here is the story. It happened to my brother-in-law's brother-in-law's brother-in-law's cousin. His name was, and still is, 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, because believed she would bring him more recognition. He worked in his attic, hurting himself in everything, and proudly published his 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 had saved using his work. Some even paid him for advice and training. He was invited to speak at one conference after another, although the badges with his name collect. He started his small business, hired a friend to work, began to dream of transcendental peaks.

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

Further worse: the GPL-project began to gain popularity, and some of Patrick's main followers began to make small patches at first, and then more and more respectable patches. And again he could not use these additions, and then he felt abandoned. Patrick was depressed, his girlfriend left him for a currency broker, whose name is Patrice, which is funny, and he stopped working on the project at all. He felt betrayed and miserable to tears. He dismissed his friend, who took it hard and then always didn’t respond very complimentary 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 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 replied: “Because a restrictive viral license.” “Let you have a doctorate and let you be the cousin's brother-in-law of my colleague's friend, but you are an idiot, and Monica did the right thing to leave you. You published your work, offering people to steal your code, and when people did just that, you were upset. Worse, you behaved hypocritically, because while they were doing it secretly, you were happy, but when they openly stated it, you felt, you see, abandoned. ”

Watching how your work was captured by a more cunning team and using 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 seem offensive, but you just don’t take it.

BSD is like a treat. I literally (actually metaphorically) hear the whisper "drink me", in such a quiet voice, which happens to speak to you a bottle of the best beer in the world - and this, without a doubt, Orval, brewed by the ancient and almost disappeared Order of the silent Belgian monks Les Gars Labas Qui Fabrique l'Orval. The BSD license, like its closest clone MIT / X11, was specially developed by the university (University of California at Berkeley) in order to issue work or effort without self-interest. It was a way to push subsidized development at a price below cost, price dumping to enter the market. BSD is a great strategic decision, but only suitable for large, well-funded institutions that can afford to use the First Method. Apache license - the same BSD, only in a suit.

For us, captains of small business, who recount their funds as the last bullets, a leak of work or effort is not acceptable. It would be great to reshape the market, but we cannot afford to subsidize our competitors. The BSD networking stack led to the emergence of Windows on the Internet. We cannot afford to fight 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 we choose affects the economy of those who use our work. There are friends, enemies, and food in the software industry. BSD exposes us in the eyes of others for lunch. Closed code - enemies (do you like paying people for programs?). However, the GPL, with the exception of Patrick, is allied. Any ZeroMQ fork is licensedly compatible with ZeroMQ, until the moment when we encourage fork as a valuable tool for experimentation. Yes, it seems unusual to watch someone take a toy from you and mess 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. This is how we built or cultivated or keenly introduced the ZeroMQ community into the world.

As a community leader, your goal is to motivate people to get there and explore, convince them that it is safe for them and for those around them, reward them in case of successful discoveries and ensure that they can share their knowledge with others (not because we ask them, and not because they are generous, but because such is the law).

This is an iterative 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 a real hit, then the community will help develop and build the next version, and it will be more.

And then this community will create the next version, etc. Obviously, while you remain part of the community, perhaps even the most important of its members, but the more control you want over the 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 enough and simple enough to get people out of bed in the morning. Your community should attract the best people, and this requires something special. In the case of ZeroMQ, we said that we were going to create the “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 would connect all the moving elements of your enterprise cheaply and flexibly,” we would have failed.

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 emotions from using your labors. They must feel something, and if you carefully solved at least one big problem that they had not even realized before, they will be with you in a small part of the soul.

Your work should be easy to understand, use and attach. 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 a task tracker there.

If you do it 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 study the landscape of the problem well. They tend to make big mistakes. Diversity always prevails over education.

Stranger, may I introduce you to the Stranger

How often should two people coordinate their actions in the event of joint work? In most organizations, very often. But you can reduce this need to zero, and then people will be able to work without even meeting them personally, without taking part in a teleconference, on a business trip, without discussing Roles and Responsibilities surrounded by an indecently large pile of bottles of cheap Korean rice wine.

You will need well-written rules, developed by someone cynical, like me, to call on strangers for mutually beneficial cooperation instead of conflicting. GPL will be a good start. GitHub and its fork-merge strategy will be a good continuation. And then you need something like our rule book C4 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 common mistakes people make: for example, such a sin as working offline in a secluded place with others “because it is faster”. Transparency is key to gaining trust, without which, in turn, there will be no scale. Let every change be visible as the whole process, and then you can completely trust the results.

Another mortal sin that many open source developers fall into is the notion that they are above the rest. "I started this project, besides my intelligence level 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 everyone 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, fair and respected rules.

Unlimited property

One of the most regrettable fictions of the knowledge industry is that ideas are proprietary. This medieval nonsense should be buried following slavery, but it still brings too much money to too many influential people.

Ideas are cheap. But what is property is the hard work that we do when creating the market. “He’s both sunk and burst” is the right model for inspiring people to do hard work. Whether it is a moral authority in the project, money for consultations, sale of the trademark of a rich and large company: if you did it, 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 (there are too many things in life, for which I am grateful, and we cannot list everything here, because we only have a hundred pages or so but this is one of those things).

You will not be able to scale a single project with many owners as you could scale several small projects, each of which has fewer owners. When we accept the fork, a person can become an “owner” by clicking once. And then he needs only to convince the rest to join, showing them their unique value.

Therefore, in ZeroMQ we sought to facilitate the process of writing binders on top of the root library, but we ourselves stopped trying to do them. This gave others the opportunity to do this, to become their owners and to credit it.

Translation of the book "Social Architecture":

• Preface. Crowd wisdom
• 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
  - Psychology of software architecture
  - Importance of contracts
• Chapter 6. Living Systems

---