<转> How to manage open source software community: Open Source project Management method

Source: Internet
Author: User
Tags bug tracking system manual jboss


This post was last edited by Jimila on 2012-10-5 12:55

Transferred from: http://www.12306ng.org/thread-911-1-1.html

Original: http://www.ltesting.net/ceshi/open/kyrjcsxw/2012/0713/205272.html

How did the open source community form? How does open source project manage?


In this article, I'd like to share some of the management tools and collaborative processes I've used in the AS7 development process, as well as some understanding of the open source community. The AS7 development process involves a number of core tools such as:
github– starting from AS7, almost all of JBoss's code base for all components is transferred to GitHub.
Jenkins–jenkins formerly known as Hudson, is a CI (continuous integration) tool. AS7 uses it to automate continuous testing of code.
Jira–jira is used for root tracking bug, record development task and so on.
It doesn't sound much different from the common project management process: Almost all projects have a code repository and a bug tracking system. (Of course, there may be projects that do not have integrated test environments or unit tests, and quality control is largely manual-this is the case in projects with lower levels of management.) )
So when a community project is scaled and matured, it can be managed well with a management tool that looks like no other person, what's the secret? I think the gap is mainly reflected in the process details, the use of tools, testing the degree of automation of these three parts.
As for the JBoss community, I would like to share some specific experiences. First we need to know that the JBoss community's bug management system is located at:
Https://issues.jboss.org/secure/Dashboard.jspa
If you have a community account, you can log in and see how many items are in the pipeline. Here is a screenshot of some of the items:
You can see that the entire JBoss community project size is very large, and many of these projects are created as components of JBoss core product JBoss AS7, and can be used independently and in conjunction with other community projects, such as Hibernate, one of the JBoss community's products.
Most of the developers in the community of these projects do not intersect, and are developed in their own projects. There are also a handful of members who contribute code to several projects, typically Red Hat employees (Red Hat also looks at the contribution of the code in the community, and the larger non-Red hat employees are often dug into full-time jobs).
People who may not know much about the workings of the open source community will think that the community is "flat", that everyone is free to submit code, that a lot of people contribute code, and then a good project is born and grown up. This is probably the biggest misreading of the Community model.
On the contrary, the composition of the community is more like a pyramid. The core developers who really make up the community are generally 3 or 5 people who tend to have very strong coding skills and a lot of experience, and they can basically contribute 80%~90% code to the project, and project design is done by these people, who may be both standard-makers and code writers.
Take JBoss Project Resteasy as an example:
Http://www.jboss.org/resteasy
The project's community leader, Bill Burke, has multiple identities: first he is a red Hat employee, and then he is a member of JCP, who participates in the development of several Java EE standards, including Ejb,jax-rs, while the JAX-RS standard framework is implemented: Resteasy The core was written almost entirely by him, and he worked on coding in multiple communities. And Bill Burke, one of the founders of the JBoss community, is commercially successful as a technical person, and his wealth is not lost to Red Hat core management.
Then look at the core members of Resteasy's team:
Https://community.jboss.org/wiki/ResteasyContributors
Almost all are Red Hat employees, enjoy the company's good treatment, engaged in community-specific work. In addition to JBoss's "commercial" community, which is directly supported by Red Hat, we look at some of the open source communities supported by the Open Source Foundation, "Pure bloodlines". For example, some projects in the Apache community, take httpd as an example:
http://httpd.apache.org/
There is a get involved link on the left, divided into three parts: mailing Lists, Bug Reports, Developer Info.
As you can see, code development is not all part of community development. First we can subscribe to its mailing list, a general understanding of the daily work in the community, and then we can find the problem after submitting a bug to the community to solve, and finally developer Info, which can be found in the code base:
http://svn.apache.org/viewvc/httpd/httpd/trunk/
Look carefully at the contributors and find that the number is not too much. In addition to the Apache Foundation's own core membership, there are a number of employee contributions from various companies involved in the development of Red HAT,IBM. In Red Hat's security team, many of my colleagues are also developers who contribute code to httpd.
So we need to be clear about the concept that community equality does not mean that the community is "flat", and that all the communities I have been involved in are almost pyramid-sized: The core team is small and refined, contributing most of the code, often working in a commercial company, or doing professional work in research institutions or open source organizations- Technical mania and a lot of spare time to participate in community development, and has formed a great contribution to the people also have, but definitely not in the community within the mainstream situation.
And what does it mean for the community? Of course, the code is written well, it has to have a user base. Therefore, the popularity of the project depends on the size of the user, the vast majority of user groups will not contribute code, but will contribute to the use of ideas, BUG reports, will help the project intentionally or unintentionally to do propaganda, contribute to a variety of peripheral projects (such as the Linux kernel community will receive the manufacturer contributed driver code, This is certainly because the manufacturers have their own business interests. )。 Therefore, the community is an ecosystem, must have the sunlight, has the air, has the water, has the birds and beasts insects, it only then prosperous.
Regardless of whether the community is commercially successful, there is a tendency for each well-run community to have a convergence of management patterns behind it. This model should be said first in the Linux kernel application, we cannot but say kernel first use of this GIT-centric code development process is very realistic, and help kernel business success.
So let's take a look at GitHub and why is the JBoss community moving almost everything to GitHub? Because its code-management process fits very well with the pyramid structure of an open source project. GitHub requires that the pull request process be used to submit the code. This process has several features:
All developers are not allowed to submit code directly to the project library
All developers must fork the project into their own space and write code in the project they fork
All code must be submitted as patches to everyone's shared project library.
All patches submitted must be audited by the team's core members before they can be put into storage (in some projects, there is only one person with this power.) such as Linux Kernel, some core modules, such as memory management and process scheduling, only Linus I have patch merge power)
For example, I want to give the Resteasy project code:
Https://github.com/resteasy/Resteasy
First I'm going to fork the project into my own space:
Https://github.com/liweinan/Resteasy
Then clone comes out to make changes, commits the changes to its own code base, and patches the modified content into Bill Burke for review:
Https://github.com/resteasy/Resteasy/pull/35
As you can see, moving the code base to GitHub is not just about changing a code base management tool, but it's a change in the overall process management. This code-management process around Git is a model that has been used by the Linux kernel community for a long time and is a direct continuation of the successful experience of community management. For GitHub's pull Request, you can refer to:
http://help.github.com/pull-requests/
Next we talk about quality control: in the JBoss AS7 project, the test process is basically fully automated, all the tests must eventually form unit test code, the use of the technology is very rich, including: Junit,arquillian, Selenium and so on.
These may not be the same as other projects, but AS7 's quality control process is not only automated to this extent, it is also automated in all "connections". These links include:
Automatically perform project tests when patches are submitted in GitHub.
The bug report in Jira is associated with a patch in GitHub.
With these two points, from the code submission, to the test, to the bug tracking record of the process is all linked together, intermediate links do not require manual intervention.
Take a look at the connection between GitHub and the project test, specifically the patch submission request from AS7:
https://github.com/jbossas/jboss-as/pull/1676
Notice the two logs:
As you can see in GitHub, this user merges the patch with the code in the AS7 Jenkins test server and triggers the test work to occur: Jboss-as-pull-request
Http://lightning.mw.lab.eng.bos. ... job/as7-param-pull/
Jboss-as-pull-request This user is actually a robot that is used to periodically find patches submitted to AS7, perform the combined test work, and ultimately give the test results. The address above is the location of the Jenkins test server in AS7, which can only be seen from GitHub and not accessible from the extranet. So I take a screenshot of the server running as follows:
For the use of Jenkins, this article is not ready to open the explanation, interested in reading this article: "Continuous integration based on Jenkins"
Let's take a look at how the code flow above GitHub is combined with Jira. Try opening a AS7 bug report to see:
https://issues.jboss.org/browse/... tabpanel#issue-tabs
See a column like this:
GitHub's pull reqest is tied to the bug report. This is done through the plug-in between Jira and GitHub. Here is the process associated with Jira and GitHub, which was implemented in Jira:
Link the code to bug management with link pull Request in Jira.
In addition to code-related content

Related Article

Contact Us

The content source of this page is from Internet, which doesn't represent Alibaba Cloud's opinion; products and services mentioned on that page don't have any relationship with Alibaba Cloud. If the content of the page makes you feel confusing, please write us an email, we will handle the problem within 5 days after receiving your email.

If you find any instances of plagiarism from the community, please send an email to: info-contact@alibabacloud.com and provide relevant evidence. A staff member will contact you within 5 working days.

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.