Selecting the principles of open source projects

This weekend, Ali Group will do school in Central South University. As an alumni, I was invited to make a technical share for a new graduate. I would like to talk about the issue of open source.

Due to the short period of technical sharing, I want to disclose it in the scene. So write a related child topic first on blog: What is my basis when choosing an open source project?

In the process of developing software, there are always some modules that are general, in addition to its own development, using a suitable License open source project is also a good choice.

In a programmer’s career, there will always be such a stage, not willing to use the code developed by others. If it is not forced by the project progress, I would rather be realized. This is not because I believe that I can always do better, but I hope to be less honest and can be free to play. Moreover, writing code is often simpler than understanding code. The code integrated with multiple different teams is also more difficult to ensure the consistency of the various parts of the project.

If you have passed this stage, it is not so attached to the wheels yourself. Which wheel chooses you will accept your picky vision. After all, press the impulse of yourself, and choose to choose a suitable.

From my perspective, first, the open source project I will first will be an active project with a complete update history.

Software code, which is not composed of a row code line, but on the timeline, by a secondary deletion modification. Snapshots at a time point cannot help me understand the software, don’t talk into your own system; any problem, as long as someone is paying attention, it will inevitably evolve. The real user is the most valuable wealth of the software project. A project that is no longer updated in a few years has become a dead project (there is a loss of all users). We should not integrate death projects into live projects under development.

If a project has been active, it is already dead, then it explains its previous user has left. If you still want to use it, please confirm that you have no energy to make it live. Even a live project, you are also likely to be unique external users in addition to the original authorities. New users mean new demands and new bugs. You must have the ability to solve the new problems.

Second, we must see if the leader of the project is good at communicating.

Most open source projects have a soul person, usually the initiator of the project. He can be tempered, but it is necessary to make truth, you can communicate; this Issues and Pull Request that you read the project can feel. If it is a relatively new project, there is still no many users, so you can also look at other items under the same name. For a period of time, I found BUG, ??mention a few orders, there will be more intuitive feelings.

Any basic function, as long as the user is enough, the demand is definitely a change. This soul person of the project plays an analysis and mediation of these needs. Is his communication skills, not coding, determines the evolution direction of the project.

Finally, let’s take a dedication of an open source project. I personally tend to solve the single problem project, you can do less less. I don’t want to use the big things of all. This will facilitate our assembly, do hub. And once it is not suitable for a while, it can also fall back and choose another plan.

As for the quality of the project quality and code, I think it is something that is a good thing, there is no fixed standard. I can endure without comments, naming irregular, indentation, no test cases. Interface continuous changes, bug layers are not poor, and it is not a big problem. Because when choosing and retreating a open source project, it means constant follow-up, participate in it, and improve it together. Large in order to change to another similar module, or rewrite it yourself.

Choosing an open source project is actually a partner of people who choose to maintain projects. Talent is the most important factor: choose diligent, open, and focused partners.

PS. Try some other domestic so-called open source projects. After doing some vast propaganda, throw a snapshot of a version of the code, and then don’t update a few years. The last few submissions, and the merged PRs are all irrelevant TYPOs. Open source is really not playing like this.