Power, money and open source. We describe how the community works on the example of Apache Ignite



    At the last Apache Ignite community meeting in Moscow, I talked about:

    • Open source community;
    • Power and money in open source;
    • How to become a contributor and a committer, and why it is needed.

    The limited time of the report did not allow to give more examples, so I spread the extended version on Habré. Everything stated is based on my personal experience and is not the official position of any company or organization.

    What is a community?


    This may seem obvious, but still let's clarify what we mean by community. First of all, we are talking about the online community. This is a kind of platform for people to interact with each other. If a community is dedicated, for example, to health, fitness and similar activities, then its task may be to support its members. Or the community can create a socially beneficial good. This is true for the open source software development community. In addition, if you have a desire to develop some kind of software, then you are unlikely to find people with similar views, for example, on their landing or in a nearby staircase. Such projects are, but usually as a student. And the online community clears the barriers between continents and time zones, allowing you to find more enthusiasts.

    Apache foundation


    The Apache story began in 1999 from the HTTPD web server: a group of people began to develop a web server, users began to arrive, some of whom began to send patches because they wanted to improve something in this product or fix bugs. Developers gradually began to allocate the right to push to the repository to the most active members of this community, which is now called committer rights.

    Applying the same approach to the development of open source, Apache has now become the largest organization (foundation) that develops open source software. The organization is divided into 319 (so far) diversified projects, of which about 200 Top-Level. There is no single process for all projects, all participants are volunteers, their work is never paid by the organization.

    Apache necessarily requires all projects to have:

    • Legal policy;
    • Brand use policies;
    • Voting on the adoption of releases;
    • The use of mailing lists;
    • Information Security.

    Apache incubator


    To build a community, all Apache projects must pass through Apache Incubator. This is an intermediate stage of development, not even a project, but a community around it. No one in Apache will dictate which technology to use. Moreover, they will not even suggest which solution to choose. The task of Apache Incubator is to build a community that makes decisions together. It is very important that the participants understand how and who makes the decision, where they can speak, where their voice will be heard. The ASF organization helps by attaching a mentor to a project.

    Top Level Apache Project


    If a project comes out of Apache Incubator, it can become a top level project. Apache helps the project to participate in conferences, provides all possible assistance in promoting the brand, supports the infrastructure.

    The top-level community project guarantees users that:

    • The code can be legally used;
    • High quality code;
    • Observed information security: for example, all releases are signed;
    • The project will always be available to users.


    Open source and power


    Now let's talk about power and money, and how decisions are made. This is not always obvious even to community members. In the Apache-project there are several roles and several mailing-lists correspond to them:

    • User (user@project.apache.org);
    • Developer (dev@project.apache.org);
    • Committer (dev@project.apache.org);
    • PMC (private@project.apache.org);
    • PMC Chair (private@project.apache.org).

    Then you can grow within the framework of the Apache Software Foundation itself, become a mentor of a project, help other projects build a community.

    The higher the role, the fewer people perform it, that is, an inverted pyramid is formed: the most users, the least PMC. Usually everyone is interested in participants growing up and fulfilling a higher role.

    Unlike commercial companies, where staff and growth is limited by the budget, in open source there is no such thing, nothing limits the number of committers or PMC. The group regulates itself independently.

    User


    Users are all of us. Surely each of you uses some open source software. For the community, it is important that the user not only uses or gives feedback in the form of bug reports or feature requests, but also helps others. That is, from the point of view of a community, a participant becomes a user only when he signs up and responds to the user-list and helps the rest to master the product, share their knowledge.

    Developer / Contributor


    If the user is ready to contribute to the project, then with the first contribution he automatically becomes a contributor, or the developer is synonymous. The contributor participates in the developer mailing list, which discusses everything related to contributions to the community. All developers influence decision-making by the community, all criticize decisions and offer alternatives.

    Committer


    If a community believes that a person has made a sufficient contribution, it can be granted the right to push into the repository, that is, the minimum number of reviewers of its code is reduced to zero (although in Apache Ignite, committers still sometimes go through code review). Committers sign the ICLA ( Individual Contributor License Agreement ) license . However, it can be signed and to obtain committment rights. The committer receives a mailbox on apache.org and can make decisions related to each contribution to the project.

    PMC Member


    PMC (Project Management Committee) Member - member of the project management committee. This community member has already made a great contribution to the development of the product and is empowered to make long-term development decisions, controls the project, and oversees many aspects, in particular, joint decision making. He helps community members come to a consensus. PMC has a lot of responsibilities in Apache, for example, it can vote for accepting a release. The committer and contributor can also, but, unlike them, the PMC has a binding voice. PMC may offer candidates for committers or new PMCs.

    PMC Chair


    The PMC Chair is a connecting bridge to the Apache Software Foundation Board. Perhaps, PMC Chair has no special authority compared to PMC Member. But he must solve the problems and report to the Apache Board on the status of the project.

    Decision Making: Duocracy


    In Apache, the principle of duocracy prevails (do-ocracy, from do - “do”). The more you do, the more opportunities you have to do, the more you influence the project.
    If by some decision you need a coordinated position of all participants, a vote is taken. It lasts at least 72 hours so that everyone can vote.

    Participants of voting put:

    +1: “for the decision”.
    0: "I do not care."
    -1: "against the decision." In this case, you need to offer something else and explain in detail why you vote against.

    There are other types of voices:

    +0: ​​“The idea is not very pleasant, but it suits me”.
    -0: "I will not interfere, but it is better not to do it."
    -0.5: "I don’t like the idea, but I can’t find rational arguments against it."
    ++ 1: “Great, let's do it!”
    -0.9: “I don’t like it, but if everyone wants it, I’ll not put sticks in the wheels, roll it.”
    +0.9: "The idea is cool, I like it, but I do not have the time / knowledge to help."

    Lazy consensus (Lazy consensus)


    There is a decision-making policy like lazy consensus, or approval through silence. This procedure also lasts at least 72 hours. If a person clearly wrote: “I want to carry out this decision through a lazy consensus”, then after three days, even if no one answered, the decision is considered to be accepted by the community.

    Endorsement and consensus approval


    Voting for the release takes place more actively: in this case, the approval of the majority of community members is necessary: ​​three binding-votes (from PMC) “for”, and more votes for, than “against”.
    Consensus is the best option: everything is “for”, and there should be at least three PMCs.

    Veto


    A qualified contributor, usually a PMC member, can impose a veto. He votes -1 for code modification and writes a detailed explanation. This decision PMC member can not get around anyone. You cannot veto a release, but if the edit is very bad, for example, it makes a breach in security or worsens performance very badly, then PMC can vote -1. And until he withdraws the veto, it is impossible to apply the edit.

    Meritocracy


    Another principle that is close to duocracy. Literally, "meritocracy" means "the power of the worthy." In open source, this means that if the user, as the group believes, has done quite a lot for the community, then he is promoted to the committer. You may ask, how fair is this decision, is it always absolutely fair and balanced? This is an extremely subjective decision of all PMCs of this community. In large communities like Apache Ignite, this policy may be more or less formalized. Certain human contributions are important, and active participation in the development mailing list is required. But “sufficiency” is determined by each project separately.

    The important point is the human qualities of the participant. Apache policy explicitly states that a person’s interaction with other participants is evaluated, how he behaves, if his opinion is not agreed. In order for a member to be promoted to a committer or PMC, other PMCs must vote in the private list, and there should not be a “no” vote.

    Open source and money


    This important topic comes up anyway: how to make money with the Apache Software Foundation products. The organization provides the most business-friendly license of all that is available. You can sell Apache-based products or support Apache products, you can use them in commercial products.

    An important requirement: there should always be the possibility of free use of Apache products. They are managed regardless of commercial interests. PMC is following this.

    A committer may receive money from a third-party organization for contributing to the project. A committer can be hired by a third party. Recently, community members told on Habréhow they work with the open source Apache Ignite community at Sberbank-Technologies. But the Apache Foundation never pays committers. This is a principled position. For Apache, the committer is always a volunteer and private person. That is, the company can not participate in Apache projects, only one developer can.

    Why and how to join open-source


    Why start contributing to open source projects?


    This is a good opportunity to upgrade your skills and earn a professional reputation. Commercial companies value participation in open source. Many famous developers are involved in various projects, becoming committers and PMC.

    What prevents people from participating in open source?

    • “You have to be an olympiad or a senior with 20 years of experience, otherwise I can't do it.” Not really. Apache Ignite is a complex project, but even here you can find simple tasks. For example, easy tickets and documentation tasks that are designed to better describe the project. Nowhere in Apache does it say that in order to become a committer, you need to write code.
    • "I need free English, otherwise I can not do it." Those who participate in the dev lists will confirm: they don’t need to be fluent in English. In addition, the communication is written and not at all in real time, there is time to think and write a balanced answer.
    • "If I send my component to open source, I will never be able to use it again." In Apache this is not the case. You can continue to use your component in a commercial product, it will just exist within the Apache Foundation under the Apache license.
    • "Everyone will read what I write on the Internet." Even in the Apache Ignite community, not everyone reads what we write. It's like a joke about the elusive Joe: no one can catch him, because nobody needs him. I’m sure my friends and relatives don’t read what I’m writing in the dev list because they don’t care.
    • "It will take all my free time." This is partly true: participation in the community is dragging its feet. If you start to participate in the discussion, it will take some time. And as your growth will take more. The more you know, the more you can tell, the more you participate in user and dev.list. But, again, there is no obligation to Apache. Each regulates their own involvement. If you can make one patch, make one patch. And everything, no one will force you. Even when a person is appointed as a committer, the letter of proposal states that he is not required to be more involved than he is ready to give.

    How to start


    If you want to participate in Apache projects, you will need an account on Github, a mailbox, registration in Apache JIRA and, possibly, in the Wiki . Any community has for beginners an article How To Contribute , Apache Ignite also has it.

    It is a good tone to write a welcome letter: “Hello! I am such and such. I want to make such a ticket, my nickname in JIRA is such and such . This letter is important in terms of assigning the role of a contributor to a user.

    Mailing Lists


    To interact with other members, Apache requires the use of mailing lists. I sometimes hear discontent: why is it so old-fashioned? There is also a bunch of chat rooms, instant messengers. This is done because every Apache project participant is a volunteer. He may have his own family, work that is not related to open source, his hobbies. He can not answer in the chat online. Perhaps he can check mail every three days. And in such situations, mailings work fine.

    Also, do not forget that community members are scattered around the world. And the person to
    whom you ask a question can be on another continent and will answer only tomorrow.
    Therefore, patience and courtesy - those qualities that are very important when corresponding in the mailing lists. For example, in the Apache Ignite community, experienced members will never write that they do not agree with you, they will write that they are not sure that they agree.

    Example letter:

    Hi, □□□□□□□, I am not sure I agree, because ...

    Community is more important than code


    One of the principles of Apache: community is more important than code. This means that the first thing Apache project aims to create a community around an open source project. And then the magic begins and a good code appears. If you do not agree with any letter, set it aside for 4 hours, re-read and postpone again. Then there is a great chance that you will respond with restraint, without pushing away with the careless word of other members of the community. We are all volunteers, and if people are uncomfortable, they will start leaving, and for an open source project this is a very serious risk.

    Recommendations on correspondence


    They are more or less similar to those used in ordinary business correspondence. If any sentence can be interpreted wrong, it will be interpreted wrong, especially considering the size of the community. All recommendations are reduced to three basic principles: to be positive, constructive and respectful.

    An example of a not very good letter:

    Hi, □□□□□.
    This solution looks a bit ugly for me.


    A wish from me as a member of the dev list: write short letters - three paragraphs or 7 sentences. We are all techies and want to give as much detail as possible. But if there are too many of them, perhaps this is a reason to write a separate article.

    What to contribute?


    Every community has a list of what it needs right now. Ignite has a list of simple tickets. If you have found a bug during use and have fixed it in your fork, you can easily create a JIRA issue for this case, make a pull request and write to the dev list.

    How to pass code review


    While you are new to the community, you can hardly determine which ticket is a priority. It may make sense to contact the person who accompanies the component; your help will be very important to him. You can also ask in the dev list which tickets are more important.

    If there is no answer, again we remember that all are volunteers. It may be a good idea to remind you about what to do in three days.

    In Apache projects, including Ignite, there is no project manager role that would monitor backlog, so irrelevant tickets can be found there. It is recommended to first write to the dev list and clarify.

    Another feature of Apache: in a commercial company there can be a clear policy that an employee of a certain level can get access to the documentation and edit it, but an employee of a lower level cannot. Apache doesn't have this. If there is anything to be licensed, no problem. I think that in any project you will not have problems with obtaining access rights, and it does not matter if the person is not formally a committer.

    Tell about the project


    The community is greatly helped by product articles. The Apache Software Foundation itself helps with conferences. You can also describe your interaction experience, not only with Apache Ignite. It may be some interesting use-case, student work. They are always published in the dev list.

    Also popular now: