It is said that what distinguishes humans from beasts is that they use and even invent tools. In the absence of any other tools, we can only rely on our own limbs. Once we have tools, our abilities will be greatly increased.

However, from another perspective, tools are also limiting our capabilities, and even limiting our behavioral patterns and thinking patterns. There is a saying that goes well: “With a hammer in your hand, everything you see is like a nail.”

In the field of R&D tools, we have observed some interesting phenomena: because the developers of software R&D tools are also the users of the tools. Therefore, they are not only limited by the tools, but are often inspired to develop tools that are more convenient for them. The phenomenon of the integration of developer and user identities makes the development of research and development tools, which can be described as “changing with each passing day”, “emerging one after another”, and even “competitiveness”.

As the complexity of software continues to increase, and the number of participants in software development continues to increase, the auxiliary software for team collaboration also begins to increase, and then we find that tools not only limit the behavior of individuals, but also further limit the collaborative model of teams .

Managers of software R&D enterprises often have a certain illusion, they think: management is to set systems, procedures and norms, and then “the people below” will implement them accordingly. Because some people are “obedient” and some are “disobedient”, a system of rewards and punishments is needed to help managers implement his “rules”. Therefore, they generally like to read books like “Execution Power”.

In the open source community, things are a little different. Although the open source community also has “leaders”, and often even “spiritual leaders”, they have no violent means, nor economic means, or even administrative means. Therefore, in order to coordinate a group of disorganized hackers to jointly develop high-quality open source software, there must be more sophisticated means.

Since everything is open, not only is the code visible to everyone, but the collaborative model of the open source community is also exposed. In a sense: this promotes the development of collaboration tools in the open source community, which in turn makes the open source R&D collaboration model evolve at a much faster rate than the internal evolution of the enterprise.

Second, the first generation of open source collaboration model

The first-generation open source collaboration model had almost no tools that met its own special needs in the early days. What was it used for? Therefore, the most commonly used Email was developed into Maillist and became the core collaboration tool for the entire development team. Most operating systems have built-in Diff /Patch tool, which makes the communication of code mainly based on Email Patch. These old-fashioned open source projects have gradually introduced tools such as SVN/Git and Bugzilla from the use of RCS and CVS, but the characteristics of collaboration around the mailing list remain unchanged.

(1) Maillist as the core of collaboration

An open source community is often a mailing list. As the software becomes more complex and the community continues to expand, the mailing list will continue to be divided. It is usually divided into: core group, development group, and user group. The mailing lists for development and user groups are further broken down as the software’s architecture breaks down into modules.

In the mailing list, all users are equal. In the absence of tools to guarantee the process, the community has gradually developed a set of strict mail etiquette and format specifications. Irregular emails will not be ignored; rude guys will even be kicked out.

There are more and more emails, and even if split into multiple mailing lists, it’s still too much. A tool like Archive for archiving and checking emails is a must. An email, everyone will reply, the title of strict re: constitutes a traceable clue.

In the mailing list, the name of the individual usually appears, plus the marks of Reported-By, Tested-By, Acked-By, which is not only a recognition on behalf of the individual, but also a part of the process specification, and also the basis for calculating the contribution of each individual .

(2) Bugzilla came into being

One of the most active topics in emails is bugs. However, it is very difficult to rummage through the mail to see the latest status of bug fixes. A bug is proposed, finally resolved, and confirmed in which version to release the Fix, which is a stable state transition mode. A proprietary processing tool is bound to emerge as the times require. A number of tools such as Bugzilla and Trac were created from this.

(3) Standardization of the code submission process

The open source community, on the surface, advocates democracy and freedom, but in fact it is elitist and even personal dictatorship. We often refer to the founder of an open source project as “the benevolent dictator.” Whether it is benevolent or not is unknown, but the dictatorship is indeed obvious.

The greatest dictatorship is the stewardship of code. As founders and core developers, they often contributed most of the code by themselves, and determined the initial structure and development direction of the project. They will not tolerate anyone committing code to the codebase at will.

On the mailing list, a new guy, never known by anyone, had to go through the hardships to be able to commit code to the codebase independently. This kind of process, simply put, is one Code Review time after time.Approved and incorporated into the codebasePThe more atches, the greater a person’s contribution to the community, the higher the credibility, and the higher his status. Then, he can review other people’s code.

totalKnot:Develop an efficient and strict community collaboration model under the condition of rudimentary tools .

3. The second-generation open source collaboration model

The second-generation open source collaboration model has two major characteristics: Web-based and integrated. With the continuous maturity of Web technology, the open source community has begun to create one after another Web open source projects, among which Web-based project management tools have sprung up like mushrooms after a rain.exist Won ikipedia,Issue-tracking Ssystems lists 55,Pproject Management Software lists 152, of which 30+ are open source,Open-source Software Hosting lists 22, which is spectacular.

Such platforms can be divided into two categories: open source-based project management tools or Issue TRacking tool, self-built platform, represented by JIRA, DotProject, Redmine; based on free open source hosting platform, represented by SourceForge, Google, LaunchPad.

The second generation of open source project management tools is mainly for development management learning within the enterprise. Documents, processes, roles, permissions, statistical reports and other functions have begun to appear. Some open source projects are also using these things.

Open source hosting platforms represented by SourceForge and Google Code eliminate the cumbersome tasks of building their own official website, management tools, and code warehouses for open source projects, which greatly promotes the development of open source projects. However, since the functions of the platform are always limited, open source projects of self-built portals and self-organized tools are still emerging one after another.

(1) issue & milestone

As the second generation of open source collaboration models matures, another trend is also emerging: agile software development. One of the most deeply rooted concepts is that each iteration completes a batch of User Stories.

In the open source community, this concept is further deduced: whether it is Bug and Feature, are collectively referred to as Issue.TheseIssue, divided into different Milestone (version), even if it may be delayed at the end,Milestone also defines an expected completion time.

This isgood thing? Or bad thing? In fact, it is difficult to evaluate, because from the original doctrine of open source: all contributions are voluntary, random, and unpredictable. Prescribing milestones for naturally grown software is inherently absurd.However, on the other hand, we can cite another example of Chinese people crossing the road – regardless of traffic lights, there are enough people to cross the road. Open source software is often notPipe milestones, stabilize a bunch of features andBugfix, just release a version.

If there is very little open source software, let alone an open source ecosystem, this haphazard approach is still feasible. But in the case of a large number of software, interdependent, an open source project to win the trust and cooperation of other collaborative projects, must give a stable plan to cooperate with each other.

This norm is also forced out.

(2) Service platformization

Although hackers like to write programs, there are too many programs to be written. It is also a good thing to have ready-made good tools that can be used directly without reinventing the wheel. If you open a website, register a user, create a new project, and take care of the rest on your own platform, then everyone can happily and concentrate on writing their own code.

Platforms are evolving so they can help open source projects take care of more and more things. Usually mainstream open source project hosting platforms can complete:

• Online code browsing and the ability to support different configuration libraries;
• Requirements management, bug management, usually merged into Issue Tracking;
• Version and milestone management;
• Document writing and management, mainly in the form of Wiki.

Further, it can be completed: simple custom workflow, folder and static resource management, output various statistical reports, and even provide forums, search, mailing lists, and various leaderboards and so on.Before that, an open source project was a community. In the era of large platforms, the entire platform constitutes a larger community.

totalKnot:The integrated open source project hosting platform provided in the form of Web marks that the collaboration mode of open source projects has entered a mature stage.

4. The third-generation open source collaboration model

With the rise of SNS websites such as MySpace, Facebook and Twitter, the collaboration model of open source projects, inspired by SNS, has also entered the third generation, a development collaboration model centered on Social Coding. This model is based on Github. On the representative website, it is most fully reflected, and many imitators are emerging one after another. In the past, open source projects and hosting platforms were built around projects, while Github was built around people who participated in open source. The first thing to meet is not the needs of the project, but the needs of individuals. Due to the greatly increased stickiness to people, Github has become the most attractive development community in recent years.

Around Github, a large number of peripheral extension services have been established, forming a more dynamic ecosystem. Programmers not only participate in open source projects on Github, but also make friends on Github, share experience and enhance their abilities. Even such a collaborative model has expanded beyond the programming realm and has become a popular model of open collaboration.

(1) Incentive mechanism

The third-generation open source collaboration model is represented by Github and its essence is Social Coding. The problem that this generation model wants to solve is the problem of incentive mechanism.

The first generation of open source collaboration, although it has created a number of well-known projects, is actually a very small circle of business. Even the most successful Linux kernel developers have only 1000-2000 people. Once people are busy, there will be chaos in management.

The second generation of open source collaboration, although drawing on many standardized management experience in the business world, is in fact not suitable for the style of open source software. For example, roles, permissions, workflows, etc. exist in Redmine. Things that actual open source projects use, but very little.

The third generation of open source collaboration draws on various numerical models in social networks. The number of followers, the number of Stars, the number of Forks, the number of Issues, and the number of Pull Requests are all marked in prominent positions, forming positive incentives for developers. There are also many statistical charts that visually show the activity level of the project.

The open source community has a very deep tradition of counting the number of patches to calculate the contribution. This is in GitHub superiorBeing carried forward, it can be said to be an excellent inheritance and innovation.

(2) Based onFork/Pull RThe cooperation mechanism of equest

exist GitHub, one click Fork its own branch, then it can be unrelated to the original branch, or it can be submitted very easily Pull Request, which brings about more frequent splits and normalizes splits.

In the original open source community, developers modified the code and hoped to contribute to the community. They needed to overcome various obstacles. If the community did not accept it, the developers could only be forced to open a new branch and become a new project.

In a state where division is abnormal, division is sinful, should not be, and will bring pain. When divisions become normalized,Pull Request has also become normalized, on and off, with a frequency of N times a day. Precisely because of this, it is no longer a sin, but a healthy, upward pattern of progress at a faster rate. Everyone is no longer under one version, each contributing, but under their own version, independent development, if you want to divide, you can divide, and you can combine if you want.

Pull Request, from a way of code merging, has become the main way of communication between developers. They found that the best communication is to communicate through source code. Everything makes sense, it is better to use source code to make sense . This is precisely the most accustomed and favorite way of communication for programmers.

(3) Extended services around Github

Compared to the previous generation platform, GitHub provides an excellent open extension mechanism: OAuth, API, SDK, WebHooks, ServiceHooks, etc., making it possible to expand various projects around GithubServices for specific needs, made very easy.

This is the evolution from the open source community of the previous generation platform to the GitHub’s open sourcestate circle”.

So far, GitHub supports a total of more than 170 different extension services, among which the more popular services are:

• Integration with other project management tools (Bugzilla, Asana, Basecamp, Redmine, JIRA, ZohoProject);
• Integrate with continuous integration services (Travis, Bamboo, CircleCI);
• Integration with message notification services (Amazon SNS, Email, IRC, Jabber);
• Integration with DevOps services (AWS OpsWorks, DeployHQ);
• GitHub open platform and API, based on GitHub OAuth API, other websites can support developers to use their own GitHub account login, and use some interesting services;
• Cloud IDE, with GitHub account login, open an IDE directly in the browser, edit yourself in GitHOpen source code on ub;
• Resume Service, according to the developer in GitHVarious social behaviors and open source project contributions on ub, automatically generate formatted resumes.

These extended services greatlylandIt enriches the connotation of the open source ecosystem.

Summarize:Communities are inherently social, and Social Coding and open source communities are a match made in heaven.

5. New exploration of open source collaboration model

(1) Git: as standard

so far,GIt’s status as the king of the distributed configuration library has been unshakable. There are at least three reasons for a preliminary summary:

1. Git with GitHub promotes each other. As the world’s largest and most popular open source community, his standard is Git.This has also led to more and more open source projects, choosingGit as standard;
2. The flames of everyone picking up materials are high, and the more people involved in development keep pouring in, the morecanhelpGit develops faster. This is a winner-take-all world;
3. The emergence of the open source ecosystem has made the Git,GitHub has developed a large number of related open source projects, open source tools and sub-communities.This phenomenon, in DAfter ocker was born, it was shown again.

(2) Code Review: Essential

The open source community has a very long history of CodeReview, even in the earliest Mail & PIn the era of atch, Review is also a top priority for open source collaboration. Just combing the review process, you can also see the development of tools and processes.

mail at first Review, then built-in on the integrated platform Review function, or provide a more powerful Review plugin.arrive GitHub innovatively proposed Pull Request, it is a more convenient and effective Review mode.

At the same time, dedicated platform-independent Code Review tools have also begun to develop: Review Board, Google Gerrit, Facebook Phabricator are some of the important representatives.

(3) Workflow: a hundred flowers bloom

exist GAfter it gradually became popular, everyone found that based on GThere are so many “plays” that it can choose from. There can be an infinite number of “paths” from the initial writing of the next line of code to finally appearing in the project’s released version.

exist gIn the official tutorial “ProGit” of it-scm.com, it is mentioned thatThree: Centralized Workflow, Integrated Administrator Workflow, and Commander and Lieutenant Workflow.

In Jiang Xin’s “Git Authoritative Guide”, it is also mentioned that based on TopGit,Submodule,Subtree,Repo,Gerrit, and Git with SVN Different working models to work with.

Later, GitFlow, Github’s Pull Request, and Github-based Github Flow and other working modes can be called a hundred flowers blooming.

Why are there so many workflows? Because the difference between the team and the project is too great. Now we can’t imagine how those developers who insist on using SVN in various situations survive?

Of course, on the other hand, too many choices will bring another kind of trouble…

(4) CI, CD, DevOps

From Everything as Code to Everything Automation is another growing trend. Two days ago, when I came out of the airport, I happened to see two billboards side by side. One of the advertisements was to the effect of: “UPS helps you open up the global supply chain”, and the other is “Bank of China helps you open up the global supply chain”. This is really interesting. It seems that in all walks of life, everyone is starting to pay attention to the connection between all aspects of the entire life cycle.

It’s just that, in the software world, we’ll feel like this is a regression. After all, initial software development is simple. On a computer, write the program yourself, compile it yourself, debug it yourself, run it, and finally release it. You don’t have to depend on others, and you don’t have to wait for any process.

As projects become more complex and more people are involved, our software not only runs on our own machines, but may also need to be deployed to a server, or published to some kind of platform. In the case of many collaborators, how to divide the labor and cooperate? In the case of uneven developer levels, how to ensure quality? Under the requirements of division of labor, collaboration, process and quality assurance, how to improve efficiency?

These are the problems that DevOps is committed to solving, and they are also the driving force behind the continuous development of DevOps.

Summarize:The open source community is always making progress, and GitHub only represents a “generation”, and a new generation of collaboration models will be created.

6. The Dark Line: The Logic Behind Tools and Customs

How was the past? What will the future hold? To answer such questions, we actually need to think more deeply: Why did the collaboration model of the open source community change? What is the logic behind the change?

(1) Two major goals of open source community R&D tools: lowering the threshold and improving efficiency

The biggest difference between the open source community and ordinary software development is that the more participants, the better.In The Cathedral and the Bazaar, Eric Steven Raymond concludes with: “If the developer coordinator has at least one good communication medium like the Internet and knows how to lead without coercion, multi-person collaboration is bound to be better than individual combat. “ThisSimply a wonderful prophecy. Although the ESR at the time probably did not predict that there would be so many related tools to assist open source based on the Internet (they only had mailing lists at the time).

Therefore, the open source community has been working on two seemingly opposite goals: “Attract as many people as possible to participate in open source in the simplest and most convenient way possible” “In the case of more people than imagined , can still maintain, or even continuously improve efficiency.”

(3) How to calculate the contribution of the participants?

Open source communities don’t pay participants, so incentives are a big issue. It can be said that it is a “rigid demand” unique to the open source community to calculate the contributions of all participants fairly, openly and impartially, and to calculate and publish various rankings in a form acceptable to everyone. Therefore, the combination of SNS and the open source community, become inevitable. In the future, big data analysis for open source collaboration will certainly appear.

(4) How to motivate, attract and reward participants?

Calculating the contributions of participants is only the basis for fair incentives. Making incentives interesting, valuable, and meaningful is the only way to attract and reward participants. Therefore, the idea of ​​gamification will be more and more introduced into the open source community.

(5) How to ensure the quality of the project?

Guarantee the quality of open source projectsofThe biggest weapon is to introduce a large number of enthusiastic testers. However, it is no longer enough for someone who is willing to test and actively and actively help to test.As projects become more and more complex, open source projects must gradually move away from relying solely on the naked eye, relying onThe quality of “many people + luck”Guarantee mode.

Automated testing and a more standardized Review process are inevitable and will become more and more important.

(6) How to work in harmony?

Freedom and regulation, planning and change, interest and responsibility, these are often hot topics of debate in the community.Although in “The Cathedral and the Bazaar”, ESR strongly encouragedBlowing “gift culture far outweighs exchange economy”, butIn a huge community, all kinds of affairs need to be done by someone, and they can’t be random.

So something like a moderator, a coordinator and a coordinating mechanism, or even an invisible hand, will slowly come back to the community.

(7) How to negotiate equally and efficiently in the community?

For now, it is still onlyIt is “online discussion + offline meeting”.Although many open source communities have begun to study meeting bibles such as “Robert’s Rules of Order”.However, meetings are still the most distressing for programmersthing. In this regard, it is worth looking forward to whether there will be better auxiliary tools in the future.