Meritocracy

In some circles, the phrase “meritocracy” is avoided, due to negative connotations caused by experiences where it is abused and perverted, restricting diversity and inclusion instead of expanding them. Because this concept is so important to The Apache Way, it is crucial that it be clearly understood.

Within Apache, meritocracy means that the more you do, the more merit you gain, and the more merit you gain, the more you are able to do. You are recognized and rewarded for your contributions, independent and separate from other factors. In other words, merit is based on the actions and contributions of the person, and not who or “what” the person is.

We want members of our community to actively participate, not just passively observe. By contributing in some way—code, documentation, fundraising, publicity—they gain an understanding of the project’s needs and challenges, and become more committed to it as individuals or organizations. If our project was a restaurant we wouldn’t just let people review its recipes; we’d invite them into the kitchen. This is central not only to the goal of meritocracy, but to the others as well.

This definition of merit, and meritocracy, allows for an extremely flat, level, and nonhierarchical playing field for all contributors. Within the ASF, and within all Apache projects, peers have “proven” themselves and thus are worthy of, and given, respect and trust. Also important in this concept is that once earned and awarded, merit does not “expire.” When looking back at the origins of The Apache Way, when all contributions were provided by volunteers doing work “on the side,” one can see how vital this was. After all, life happens and it was not unheard of that a contributor would step away for months at a time, only to return as their time freed up. If they were required to “regain merit,” it would discourage them from returning. The principle is part of the larger goal of making the bar as low as possible for involvement within a project.

Another aspect of meritocracy is that, when done correctly as within Apache, it avoids a self-sustaining oligarchy, where those with power and merit maintain and consolidate it. By creating an environment and culture where new contributions and new contributors are encouraged and welcomed, and where a governance structure makes it clear what benefits and rewards they gain via their contributions, the community itself will thrive and grow. Key in this is that no one’s “vote” or opinion is more valued, or weighted more heavily, than someone else’s. Whether one has been a member of the project for six months or six years, their vote and their voice carries the same weight.

Treating newcomers and marginal participants equal to established members is a principle that might not seem productive, but it has proven its importance again and again. Its basis is the recognition that contributors will come and go. If, when joining a project, someone knows that they cannot “compete” with someone who has been there longer, they really have no incentive to join. People want a say in the projects they join; they want to exercise some influence on the direction of the project. If potential influence is squashed simply due to being “new” in the project, why bother in the first place? This risk of repelling contributors is elegantly avoided by Apache’s very flat peer system.

The final value of meritocracy is that it provides the encouragement and incentive to get involved. It sends a clear signal to the external community and ecosystem that contributions are not only welcomed and wanted, but actually rewarded. It is the core path in that incredibly important feedback loop between users and developers/contributors.

Transparency

To describe how the Apache Group approaches this fundamental, let’s first consider software development in a typical enterprise environment. A roadmap is created by marketing and management, which defines what features and capabilities the software must have. Next that roadmap is presented to the software development team, which consists of individuals who are assigned work and tasks toward the development effort. Discussion is limited to that specific team, usually via face-to-face meetings or the normal “hallway/water-cooler” conversations, with little, if any, of it documented. Very little collaboration is done within the team, and certainly not external to the team. In effect, we have the standard siloed, self-contained, and insular software development scheme so prevalent even today.

Now compare this with how software development is done via community-based Open Source projects. The roadmaps are not as detailed or stringent, and the creation and adjustment of the roadmap are done by the developers and users of the project, usually via mailing lists or wikis. The “team” is geographically and culturally diverse, spread out over time zones and locations that make face-to-face meetings impossible. The people on the “team,” rather than being assigned, are there by choice, a self-selected group of individuals who are also self-organized. Areas of responsibility are fluid, with contributors working on areas that interest them. Instead of working on the project because it is their “job,” they ideally work on it because they are personally invested at an emotional level with the project (and its community). Even in situations where the person is paid for their work, there is a fundamental difference between someone who contributes because they are paid to do so (a “hired gun,” so to speak, or, alternatively, a “line cook”), and one who is lucky enough to be paid for something they would do on their own free time, and frequently still do (“a chef”). We have noticed that people working on Open Source projects on company time often are volunteers or at least empowered to choose the project to which they contribute, not people assigned by their managers. This shows a high level of identification with the project.

Comparing the top-down and Open Source scenarios just shown, it looks as though the “Open Source Way” would never succeed, and yet today it is clear that it is the optimal way to do software development. But this is possible only when transparency within and beyond the project is valued. In fact, it is vital.

Transparency, of course, is basic to Open Source because the source code must be available. In other words, the code itself is transparent, in that it is visible to all. But when doing software development, that is only one small facet of true transparency. Not only the code but the decisions must be visible: the decision-making process itself, the discussions and conversations—all of this must be transparent.

Transparency is important because it prevents a culture and environment that disenfranchises those not currently in the group; it enables those “outside” to have a clear and accurate insider’s view, which fosters a development community that people feel empowered to join and contribute to. Transparency is required for collaboration not only within the team, but with other teams as well, which drives innovation and reuse. Transparency ensures that all discussions and points of view are represented, with everyone having the ability to understand and question them. Transparency, almost more than anything, drives the required culture inherent within InnerSource, one which breaks down the wall between “us” and “them.”

Within Apache, this focus on transparency exhibits itself in several ways. First is the reliance on mailing lists as the primary method of communication. Mailing lists are preferred first and foremost because they are asynchronous, being unbiased in regard to location and time zone. Mailing lists are also self-documenting (all Apache mailing lists are archived), which ensures that the “tribal knowledge” held within the current group is shared and known universally. It provides a view into development history and the reasoning behind decisions. Mailing lists are also useful for their ability to thread conversations and topics, making it easier to follow items of interest and avoid others.

Another way transparency is encouraged is via the public nature of the code itself. When contributors know that their contributions will be seen “by the whole world,” the tendency is to put one’s best effort into it, which results in better code. This also has two other benefits. The first is letting contributors learn from others. The ability to mentor and be mentored is feasible only if one’s work product is visible to a wider group.

The second benefit is maintaining the crucial personal attachment between a contributor and their contribution. The importance of keeping a history of who contributed what is unfortunately seldom recognized. Open Source recognizes and acknowledges that developers are really artists, whose medium of choice is code. As with all artists, they want to hone their skills as well as share their craft, and the Open Source movement provides the environment to do so. In most typical software shops, the developers write their code and then “throw it over the wall” to QA or production; that breaks the connection between the artist and the art, to the detriment of all. Many practical disadvantages can be observed: developers lose control and insight into their code and how it is actually used in production; QA and testing are done by those unfamiliar with the code and its requirements; and developers lack “responsibility” for the code they produce—in many cases they don’t get the 3 a.m. beeper call when their code breaks in production, for example. Transparency—the ability for the contributor to point to their contribution, open and visible to all—maintains that vital connection.

Finally, transparency eases the concerns over the provenance of code inherent in all software development for licensing reasons.

Community

The third leg of The Apache Way is community. Although the other two could also be bundled as subitems under community, this aspect is somewhat deeper. In The Apache Way, community could almost be defined as the entire ecosystem around a software project. It is a recognition that not only is the community larger than the developer community, or even the developer and user community, but encompasses the wider world. Software today impacts everybody, even people (and other creatures) who don’t directly use that software.

In essence, our fundamental of community concerns a shared culture that all members of that community understand and promote. The genesis of that culture, and the model of that community, must spring from the contributors.

Within Apache projects, we do several things to reinforce that. I mentioned earlier the concept of collaboration, but it is easy to minimize its meaning, or see it as simply “working together.” Collaboration, as it relates to community, is about seeing the individual merit of each person and seeing each person as a vital part of the project itself. It means ensuring an environment, both in culture and in infrastructure, where each person can influence the project and can drive certain tasks or efforts, while still engaging the other community members as well.

One rule of thumb we use toward this goal is to discourage large, substantial “code dumps” into Apache projects. A code dump, for example, could take place if I were to refactor the code or create a new feature completely independently, and then, once complete, commit that to the codebase. In that scenario, I’m not really working with the rest of the contributors, I’m simply doing my own thing and adding stuff as the mood strikes. At Apache, what I would do is create a thread on the development mailing list describing what I was considering, maybe commit a preliminary work-in-progress (or, alternatively, create a public branch of that work-in-progress), and encourage others to work on it with me. That is true collaboration. That is a true community.

Another major part of community is driving consensus. In an environment such as Apache, no single person decides what feature to add, or what patches and contributions to accept. Instead, it is a community decision, which implies that there needs to be consensus on that decision. Within Apache we use voting to gauge this consensus; usually someone will propose something and ask for a vote, at which point people will post email messages saying +1 (“sounds good to me; I support it”), +0 (“no opinion”), −0 (“I don’t like it, but don’t want to stop it from happening”), or −1 (“I am against this and don’t think we should do this”). Now you may expect that what we do is tally up the votes and let the majority vote “win.” But you would be wrong. In general, if someone, even one person, votes a −1, we step back and continue to discuss the issue. We work on resolving disagreements and ensuring consensus within the group. Again, this is how a community should be run.

The Apache Way serves as the base model for InnerSource. Understanding The Apache Way, and using it to guide one’s InnerSource strategy, has been the basis for successful InnerSource journeys for countless companies. The next several chapters present several of these journeys.