The open source community is constantly tearing up, and it is not clean to be a programmer

Produced | OSC Open Source Community (ID: oschina2013)

Earlier this year, we reported that ” Father of Swift officially quits Swift core team after being insulted and yelled at by multiple people “.

Such incidents of “language violence” and “cyber violence” are not uncommon in the open source community and even the entire IT community. In many technical communities, founders, important maintainers, and contributors announced their withdrawal because they felt “bad community atmosphere” and “hurt”. What’s more, leaders of technology companies have been exposed to clamor for the post-80s generation to quit the IT circle. The latter can be roughly regarded as the fact that the leader is too extreme, and it is a rare case, so we will not discuss it too much. But in the open source circle, how come this is the case?

In order to answer this question, this article has sorted out some past community disputes and found that many conflicts occurred between the actual managers/layers of the community, and the community contributors and participants. The dissatisfaction between the two parties can be roughly classified into several reasons .

Difficult to reach

After shifting from the development model of the cathedral to the development model of the market, the purpose of the technical community is to gather the power of everyone to make the project better. In the market mode, the open source community gives individuals a great degree of freedom, and all contributors can speak freely, express their ideas, and contribute to the project. The question that follows is how to reconcile everyone’s opinions.

The management model of the community also determines the risk of future disputes in the community to a certain extent. The current open source community management is mainly divided into four modes. First, it is led by the community and adopts a free contribution model. “Consensus” is the premise. Important decisions such as function development and version release are subject to community consensus. The second is that the company is led by the company, and the development of the community and software is funded by the company. Relatively speaking, the company will have more real power. The third is BDFL’s benevolent dictator model, which is based on the community model. There is a “dictator” in the community who has the final say on some important decisions, rather than relying on community consensus. The fourth is elite governance. Those with outstanding performance and greatest contributions in the community are appointed as the management team, and decisions are made based on voting.

Our common disputes can often be summed up as disputes between “power holders” and “contributors”, which are more likely to appear in open source communities with a “benevolent dictator” model. In the other three models, many disputes also arise because the actual management team has not played its part.

Dissatisfaction with those in power

World-renowned large-scale open source projects are often the work of a “genius programmer”. Early open source communities are generally “benevolent dictators”, and dictators are highly respected, such as the Linux community’s Linus, Ubuntu community, and Python community. . However, geniuses seem to prefer to fight alone.

Grumpy boss Linus is very vicious when it comes to evaluating code that doesn’t meet his personal standards. Some netizens used a reply that Linus had published on the mailing list before, pointing out that Linus had a bad attitude in interpersonal communication: “This is also a bug? How long have you been a kernel maintainer? Haven’t learned to maintain the kernel yet? Rule number one? I don’t want to get this blatant garbage, idiot-like commit ever again…”

For Intel, which has always been unhappy, Linus also spit out the code submitted by it. In early 2018, to patch the Spectre vulnerability, Intel engineers provided a patch for the indirect branch restricted speculation (IBRS) feature. Linus publicly pointed out on the mailing list at the time that IBRS would cause a significant drop in system performance, and bluntly stated that the patch “is utter rubbish.”

Not only Linus, but in the BSD community that advocates “eliteism”, there is also an obvious “chain of contempt”. Bill Joy, the author of the first edition of BSD, was reluctant to trust the large number of volunteer contributors, saying: “Most people are bad programmers, and a lot of people staring at the code won’t really find bugs. Real bugs. It was discovered by a few very smart people. Most people look at the code and don’t see anything… Can’t expect thousands of people to contribute and all to a high standard.”

This view has always existed in the development after BSD. Marshall Kirk McKusick, a deep participant in FreeBSD, once said that 90% of the code contributed by the committers cannot be used, and the remaining small part also needs to be polished.

In the Python community, for many years, the father of Python, Guido van Rossum, was the most authoritative person, and he was also awarded the title of “Benevolent Dictator for Life” by the community. But in 2018, when the Python community discussed improvement proposals, Guido found that “so many people now despise my decision”.

Therefore, he did not want to fight for anything more for PEP (Python Improvement Proposal) [PEP 572] (https://ift.tt/WJi9sDH) and decided that he would gradually leave the decision-making layer and no longer Lead the development of Python and participate in the community as a regular core developer after a break.

Sometimes “benevolent dictators” are also blamed for “inaction.” Ubuntu founder Mark Shuttleworth has been dubbed the “self-styled benevolent dictator” in the community. In fact, the early days of the Ubuntu community were indeed a “benevolent dictator” management model.

However, when the Ubuntu community was flourishing and various businesses were on the right track, Mark Shuttleworth’s own work gradually distanced himself from the developers, and Jono Bacon and some other well-known core members in the early Ubuntu community left one after another, and Mark Shuttleworth also Rarely active in the community. Gradually, some senior Ubuntu developers believe that the community is facing an embarrassing situation of “leaderless”, accusing Shuttleworth of not fulfilling the responsibility of “BDFL”. A former Ubuntu developer left a message in the Ubuntu community accusing Mark Shuttleworth of “abandoning the community and keeping silent about the breakdown of community governance” as a BDFL, disappointing.

Mark Shuttleworth also embraced the responsibilities, admitting that he was not good enough in these areas, and expressing “frustration”.

The most dissatisfying point of open source projects is the “white prostitution”. Many open source projects rely on the author to generate electricity with love, and the community’s learning is greater than the feedback, which leads to physical and mental exhaustion of the software author.

Some time ago, the Apache Log4j2 high-risk vulnerability incident was vigorous, and attackers could use its JNDI injection vulnerability to remotely execute code, affecting many projects and companies. This incident also attracted attention and criticism to the author of Log4j2. One of the maintainers of Log4j2, @Volkan Yazıcı, complained on Twitter: There are only a few Log4j2 maintainers, they work unpaid and voluntarily, no one pays and no one submits The code fixes the problem, and when there is a problem, a bunch of people will leave a message in the warehouse and be scolded.

Previously, Vitaly Slobodin, one of the core developers of PhantomJS, announced that he would resign as the maintainer and no longer maintain the project, because he was too tired to generate electricity alone: ​​”I can’t see the future of PhantomJS, as a single developer to develop PhantomJS 2 and 2.5, It’s a bloody hell. Even the recently released 2.5 Beta has a brand new, shiny QtWebKit, but I still can’t really support 3 platforms. We’re not supported by other forces!”

Contributor dissatisfaction

As the community evolves with the development of the project life cycle, changes in processes and regulations are inevitable, and the atmosphere for communication between contributors is constantly changing. Contributor dissatisfaction with the community often begins when the community changes…

A Debian package maintainer, Stapelberg, wrote a long article in 2019 announcing that he would withdraw from the Debian development process and gradually reduce his participation in Debian maintenance and related activities. The main reason is that he found the entire development evaluation process in Debian to be very slow.

For example, there is no deadline for patch evaluation, and sometimes he gets a notification that a patch submitted a few years ago has now been merged. Some of Debian’s maintainers refuse to cooperate out of personal preference, and too much personal freedom given by maintainers has a serious impact on Debian.

After his frustration with Debian’s development process crossed a threshold, he quit and wrote articles in hopes of inspiring Debian to make changes.

In the LLVM community, in 2018 a senior developer named Rafael Avila de Espindola (5th in LLVM compiler contributions) emailed an announcement to part ways with the project. The reason is that the feeling has changed in recent years, LLVM is increasingly large and slow to change, and he also disapproves of the community code of conduct recently introduced by LLVM. What really drove his decision was LLVM’s partnership with Outreachy, an organization that openly discriminates on the basis of gender and ancestry, much to his dismay.

In addition, some open source projects led by companies will also lead to dissatisfaction due to changes in development strategies.

The Qt Company will make Qt 5.15 a commercial-only LTS starting in January 2021, the existing Qt 5.15 fork will be publicly visible, but will not see any new patches, and only paid accounts will be able to use the long-term support version of Qt 5.15.

This move has caused strong dissatisfaction in the community, and the concern of the KDE community based on Qt development. A user commented sarcastically under the official Qt announcement: “So basically you are telling all loyal open source users that now they will only be considered beta testers for commercial customers, and as a bonus, they will only be able to download non- LTS release. You guys are so kind!” said Thiago Macieira, a long-time Qt contributor, developer Thiago Macieira from Intel Corp., at least for code he’s worked on in Qt, and he’s no longer involved in fixes, comments, and post-reviews side error reporting.

Corresponding to the actual management team of one person or a few people in each community, contributors will rise up and resist “management” when management is not good.

A few months ago, the Rust Moderation Team announced yesterday that they had resigned en masse with immediate effect. Team member Andrew Gallant said the move was a protest against the Rust Core Team not being accountable to anyone but themselves.

Rust managers are divided into many teams, such as core team, review team, release team, library management team, etc. Among them, the Rust core team has the most authority, and other teams cannot influence them. Andrew Gallant wrote in the announcement that due to the irresponsible organizational structure of the core team, they have been unable to implement the Rust Code of Conduct in accordance with the community’s expectations of the review team and the standards they adhere to. They expressed their apologies to everyone for choosing to leave under these circumstances. But from a Rust governance perspective, they have no choice. Therefore, the Rust review team believes that there is no other way but to resign and make this statement.

How to make people satisfied?

There is only one consequence of the intensification of conflicts: members slowly leave. If the community and the project do not make changes, it is very likely that the project will decline. Since a community full of quarrels and dissatisfaction for a long time is unsustainable, how can we build a community that allows more people to participate happily?

First of all, no matter what kind of governance model the community is in, individuals can express their views in a civilized manner and abide by the community code of conduct are necessary conditions for reducing conflict. However, personal behavior is a very unstable factor. Just like Linus once said that he wanted to change his temper, but every time he was stimulated by various remarks, he returned to the irritable boss.

Secondly, it is to effectively manage the community through a governance framework, separate powers, avoid dictatorship, and restrict each other between members, and develop based on “consensus”. Specifically, a good “handbook (principles, guidelines, etc.)” and a convincing and notarized team.

For example, in the Apache Software Foundation, the elite governance model is adopted. Apache Way has clear regulations on decision-making, supervision, execution and other aspects: including a flat structure, regardless of the position, all roles are equal, the voting weight is the same, and a benevolent dictator is not allowed to appear; a single project is self-selected The active volunteer team supervises and tends to decide the development of the project on the premise of reaching a consensus. If the consensus cannot be completely established, it will make decisions by voting and other methods; the governance model of the entire foundation is based on trust and entrusted supervision…

In the Open Atom Open Source Software Foundation, there are similar regulations on the community’s need to comply with “merit governance” in the graduation standard assessment of projects:

OA-CO-40

【英】The community strives to be meritocratic and over time aims to give more rights and responsibilities to contributors who add value to the project.

【中】The community must conform to the spirit of meritocracy. Over time, contributors who add value to the project will be given more rights and responsibilities

TOC member Xu Liang once introduced that the four words of meritocracy were determined after many rounds of discussions. In the English context, the word is meritocracy, which is not entirely a compliment. “We don’t think it’s completely correct to use meritocracy to describe the community, but we also think that in the open source community, the so-called capable atmosphere is What is more positive is the main factor for the healthy functioning of the community.”

In many projects, on the one hand, everyone is a contributor, and on the other hand, the more important features each person submits, or the more meaningful contributions they make to the project itself, the more likely it is to be selected by the current maintainers to take on more important character of. Elite governance or meritocratic governance achieved in this way often hopes to allow the project to grow by itself and go on better.

Ubuntu founder Mark Shuttleworth got involved in shifting Ubuntu to a governance model after a crisis of confidence. At present, the Ubuntu community has also reorganized a management team composed of three core members, namely Monica Ayhens-Madon, Ubuntu community representative, Rhys Davies, head of Ubuntu developer relations, and interim community manager Ken VanDine. Ken will also be responsible for continuing to find a suitable Community Director for the Ubuntu community.

Finally, to borrow a current consensus: open source is more important than ever. Therefore, maintaining a good community atmosphere is particularly important.

The text and pictures in this article are from the OSC open source community