Open source changes the world, you and me

Open source changes you and me

Hello, everyone, when it comes to open source, perhaps the most obvious thing that comes to mind is open source software. As of today, open source software has been twenty years old. Nowadays, no one can ignore the great impact of open source on every area of our life. After only 20 years, open source has achieved such a great success. What is the reason for its success? How does that affect us? We’ll decrypt it for you in Part one.

Since open source is so important, how do we embrace it? Are you intimidated by open source projects? We will give the answer in Part 2.

Only the right project is good. In part 3, we will introduce how to find the right project for you.

When you find a project that’s right for you, how to get involved and how to contribute to it, part 4 will show you the right posture to start.

Open source software that eats the world

Living in the age of open source is undoubtedly fortunate. Open source turned 20 this year, which is the age of high spirits and the time of great talent if we can compare it to ourselves. Open source has made it possible for so many people, and it is the backbone of our digital age. Its existence and development significance is worth you and I to ponder and dig.

Twenty years ago, in February 1998, “Open Source” was first used by software, and in a sense, Open Source has already won, and it has gone beyond the imagination of the participants at the time. In my view, the first decade was a decade of confrontation and controversy, and the second decade was a decade of acceptance and prosperity. Let’s hear from some of the biggest names in the industry:

Google said: “Without open source software, the Internet as we see it today would not exist!” Intel says: “Open source is mainstream!” Red Hat said, “We made $2 billion using open source.” Microsoft said, “We’re very committed to open source.” Salesforce, Amazon said, “We’re replacing Oracle!” IDG said: “Open source ranks alongside ARTIFICIAL intelligence, deep learning, virtual reality and cloud computing security as the top technologies of 2017!”

This is the age of default open source:

Open source has entered the history, irreversible! Embrace or sink!

World is full of source code

Open source means open source, so is source code just software? Today’s “source code” is much broader, including blueprints, recipes, rules, user interfaces, graphic design, writing documentation, and even organizing activities.

As you know, the greatest design engineering belt of the 20th century was the democratization of consumption, and the next step in design engineering is the democratization of production. This is the secret to the success of open source projects like IKEA and WikiHouse.

When it comes to WikiHouse, an exhibition booth with WikiHouse structure was quickly built in Dashilan Community of Beijing Design Week in October 2016. The construction activity was jointly completed by 6 adult volunteers recruited online and 6 high school students. The on-site construction process only took 7 hours.

Incredible! WikiHouse provides drawings of every part of the simple house, including the connections between the panels. You can download the drawings and efficiently “print” the panels into their desired parts with the help of a CNC machine. It only takes 2-3 people to put together this simple house as easily as ikea furniture.

In addition, WikiHouse provides standards and guidelines for house design, including the use of nails and the structure and specifications of joints between panels. At the same time, it also grouped the design into different series according to the width of the house. It is this process of standardization that ensures the quality and efficiency of such open source projects.

Perfect just the way they are, simplify the complex process, let the non-professional farmers can join the work, is the goal, simplified is not equal to simple, however, is spending more time refining, structure analysis is extremely complex, especially anticipation security scope of uncontrollable factors, face the problem is still a lot, but I think this is the charm of the open source, It was through this project that I learned more interesting topics, such as ecological design, sustainable architecture, resilient city and so on, which broadened my horizon. As long as you put your heart and soul into it, I can guarantee that you will gain more than you contribute in the open source world.

Why is open source so successful

Whether you want to admit it or not, open source is everywhere in our lives. How did it go from a spark to a fire in just 20 years? What is the essence of open source? Here we come to the original source and uncover the secret of success for you! In my opinion, the most important points are as follows:

Lose all game, win-win cooperation!
Effective communication is the key to profit maximization!

First, I’ll introduce an interesting concept called the Prisoner’s dilemma

The prisoner’s dilemma

Prisoner’s Dilemma is a representative example of non-zero-sum game theory, reflecting that the best choice of an individual is not the best choice of a group. Or in a group, individual rational choices often lead to collective irrationality. Although the dilemma itself is only a model, similar situations often occur in price competition and environmental protection in reality.

Classic prisoner’s dilemma

The police arrested two suspects, A and B, but there was not enough evidence to charge them. The police then held the suspects in separate confinement, met them separately, and offered both the same options:

If one confesses and testifies against the other (” betraying “in the jargon) and the other remains silent, that person is immediately released, and those who remain silent face 20 years in prison.

If they both remain silent (the term is mutual “cooperation”), they will also be sentenced to one year in prison.

If they both blow the whistle on each other (” betraying “each other), they both get five years in prison.

commentary

As in other examples of game theory, the prisoner’s dilemma assumes that each player (the “prisoner”) is self-interested, seeking his or her own best interest and not the interests of the other. A rational participant would never choose a strategy whose benefits are in any case lower than those of other strategies. In addition, no other forces intervened in individual decision-making, and participants were free to choose their own strategies.

Which strategy should a prisoner choose to minimize his or her sentence? Two prisoners because of isolation imprisonment, do not know each other’s choice; And even if they can talk, they can’t always trust each other not to talk back. As far as an individual’s rational choice is concerned, the penalty for betraying is always lower than silence. Consider how two rational prisoners would choose in a difficult situation:

If the other side is silent, MY betrayal will let me free, so I will choose to betray.
If the other side betrays me, I have to accuse the other side in order to get a lower sentence, so I will also choose to betray.

They face the same situation, so their rational thinking will come to the same conclusion – choose betrayal. Betrayal is the dominant strategy of the two strategies. So the only possible Nash equilibrium in this game is if both players betray each other and both end up in prison for five years.

The Nash equilibrium of this game is clearly not a Pareto optimal solution for the group. In the overall interest, if both participants co-operated to remain silent, they each received only half a year in prison, a higher overall benefit and a better outcome than if they had betrayed each other and received five years in prison.

But according to the above assumptions, both are rational individuals who pursue only their own personal interests. The equilibrium condition is that both prisoners choose to betray, and the prison sentence of both prisoners is higher than that of cooperation, and the overall benefit is lower than that of cooperation. This is the “dilemma”.

Think about what examples you have in real life.

What does the Prisoner’s Dilemma reveal

When everyone chooses the rational choice of maximizing profits and minimizing losses, the ultimate result of maximizing profits cannot be obtained. Everyone is trapped in a tragic situation, where there is a possibility that you are good and I am good, but you are not good and I am not good.

If broken

In fact, in the video, the key has been revealed. That’s communication!

Prisoner’s dilemma is an example of a static game. Think about it, if two people have the opportunity to communicate, can change the final result, out of the dilemma? So they can both choose better outcomes. That’s cooperation.

But working together raises a new question: Can they trust each other, and can they resist the temptation to betray? Because betrayal can lead to a better outcome. There are two ways I know how to solve this problem, and in the first way credibility becomes very important. Credibility comes from reputation, and it can also come from consequences. If there are rules in a gang, for example, betraying a partner, they will be punished. That’s the punishment. That’s the credibility. The second way, to better illustrate, is to introduce a British variety show called Gloden Ball.

Example: To be added

This is an example of clever use of reason, the fundamental of human nature is the reason of “seeking benefits and avoiding harm”, so no matter the other party is a gentleman of his word, or a villain of selfish interests, you can achieve the most theoretical and perfect results.

The above two examples are based on the premise of communication, personal interests maximization is based on the premise of team benefit, on the basis of the simple pursuit of personal interests to maximize counterproductive, we have all outsmarted ourselves, so the game all lose, win-win cooperation, and effective communication system is the key to benefit maximization.

Important attributes of open source projects

In addition to the two key reasons for the success of an open source project, it must have the following important attributes: a well-functioning, well-regulated, freely licensed collaborative community.

For open source original clean source

If everything is open source, why do people think of open source software first? How did it become the pioneer of open source? How does it affect us? Have to have free software movement.

Free software movement

1968 was the year of the Unix operating system, created by Ken Thompson with long hair, a beard and thick glasses.

Thompson was working for Bell LABS when he wrote Unix, so Bell LABS distributed Unix source code throughout the 1970s, when research LABS, universities, and computer scientists from around the world contributed code to Unix. Unix used to be “free” software that could be adopted by any organization that needed it.

By 1979, Bell LABS was owned by AT&T, which claimed Unix as its copyright, and people had to pay AT&T to access the source code.

Programmers, who had collaborated on Unix, were beginning to resent it. At the very least, they thought, Unix should remain “free” and available to them, since they had helped Unix grow and evolve.

Then the hero appeared. It was Richard Stallman, a researcher from MIT, a hippie sort of guy, who was struck by the fact that when he and his colleagues asked for the source code for the printer driver and were turned down, he thought software should be free, and ever since, Stallman developed the idea of free software into his own mission and became a leading figure in the movement. In 1985 he founded the Free Software Foundation, based in Boston, which is still active today.

Stallman and other programmers began writing code to replace Unix. These projects were called “GNU” (short for “GNU is not Unix”), and they distributed projects using “copyleft” — a term opposed to “copyright.” Copyleft encourages users to make changes to existing code and can be kept open, with computer developers from all over the world collaborating to develop GNU and other free software projects.

Commercial software companies such as Microsoft and IBM developed their own commercial operating systems to compete with Unix. However, these operating systems do not provide users with the ability to modify, nor do they allow users to build their own versions.

Throughout the 1980s, free software developers struggled to develop a better operating system, but one crucial ingredient was missing: a “unified kernel,” the key core program that managed hardware devices and provided good interfaces for applications.

That changed in 1991 when Linus Torvalds, a 21-year-old Finnish college student, founded the kernel project. He later released the source code under the GPL and named it “Linux.” Developers began to merge the kernel with the existing GNU project. This is the Linux operating system we use today, the full name should be: GNU/Linux.

Since then, Linux development has exploded. (Under the Radar is also a book by Red Hat co-founder Bob Young.) Geeks and computer enthusiasts began to like him, and they worked together to solve each other’s problems. University professors, for example, collaborated on programming for research, which could cut costs, and they improved Linux by creating new programs and fixing bugs.

Some early Linux developers from what big companies, but their boss has a blind eye to their work, occasionally some influential economic mind executives noted “free software”, but they don’t know how to deal with, because, for them, Linux is completely strange too esoteric, and difficult to understand. Often they think it’s just “research and development” and turn a blind eye.

Find insights

In 1992, Bob Young, then a humble entrepreneur, sold his computer business and launched the Linux Journal. Bob didn’t know how to write programs, but he was one of the few people who realized the rapid growth of Linux was a business opportunity.

“At the time, the people who worked at the big magazines in California completely ignored Linux,” Bob says. “It seems to me today that they realized that, just as I thought ‘That’s the direction’ when I looked at Linux in ’92.”

“In ’92 and’ 94, free software didn’t disappear,” Bob recalls. “Instead, more and more people were using it, and I thought, ‘Well, that doesn’t mean anything, that doesn’t fit my worldview. ‘And none of the engineers I talked to had any idea of a business model for free software, and if you don’t have a business model, you can’t have any business success.”

“I decided I wanted to do something,” Bob recalls. “The development of Linux itself had upended my view of the world and rediscovered that altruism was possible (though I hated to admit it) and that there was something going on here that engineers couldn’t understand.”

To solve this dilemma, Bob decided to ask these Linux experts himself, hoping to find the answer: Why don’t Linux programmers file patents? Not selling their code? Why not capitalize a technology company like Linux?

One of Bob’s stops was the Goddard Space Flight Laboratory in GreenBelt, Maryland, where a RESEARCH facility owned by NASA began installing Linux. It was this trip that inspired Bob to create red Hat’s unique business model in the first place.

When Goddard made a big change to Linux, replacing the $500 supercomputer he had bought three years earlier with $40,000 worth of PC servers running Linux, Bob interviewed one of the programmers who worked there. A developer who had written Ethernet drivers for Linux intended to use the code in Goddard’s project, but he also posted the code freely to the community for public use. Bob wants to know why he did it.

Bob asked Tom Sterling, the programmer’s manager, “Why are you spending money on these complex Ethernet drivers? Aren’t you going to sell them?”

“We just submitted the Ethernet driver in return,” Tom explained. “You know, we got the source code for the entire operating system, we could install it on any machine, and I was free to do whatever I wanted.”

Bob continued, “Why don’t you run Linux on any mainframes? As far as I know, Sun Microsystems is more than happy to give you the source code if you want to develop it on their system.”

Tom then explained, “You’re right, I could ask Sun Microsystems for the source code, but if I did, I’d have to talk to my lawyer and find out what I could and couldn’t do. If I use Linux, the license allows me to do whatever I want.”

Tom’s answer solved Bob’s long-standing puzzle: control is what users really care about, not functionality.

“So Tom didn’t use Linux because it was better, or cheaper, or faster,” Bob adds. “He uses Linux because it gives him control, and he can’t find an alternative, whether it’s IBM or Microsoft or Sun or Apple. No commercial company can give him that benefit! I’m a salesman! I never sell features, I sell benefits! As Tom put it, Linux offers one advantage that no other vendor can offer — control! So, since that trip, I’ve been inspired!”

In 1994, Linux was still in the dark, at least as a managed operating system. Proprietary software companies ignored it and considered it still under development, so the big software companies didn’t see Linux as a threat. But Linux quietly grew, growing to 1.5 million units in 1995, up from 100,000 in 1993.

Looking back through the 1990s, more and more organizations started to adopt open source solutions, which finally made things better. This is the result of years of persistence, and it probably wouldn’t have happened if there hadn’t been an open mind and creative thinking involved.

What is revealed?

Find your competitive edge. Most companies promote the features of their products, not the benefits, which is what people really care about. What benefits does your company offer? Is it control? Or will it save time?

Community is better than code, independent fast, crowd far!

Are efficient, healthy FOSS projects created out of thin air? Why is community so important? What does a good neighborhood look like?

Executive Vice President, Apache Software Foundation 2014: The Apache Software Foundation has developed some unofficial motto over the past 15 years, which has been passed on by word of mouth: Community trumps code.

For the community, everything is built around code, and without code the community would not exist. Above the code is the idea of how to do things, how to treat people and how to make decisions. In its 15 years of existence, the Apache Software Foundation has over 150 world-class projects, over 500 individual members, 4,000 contributors, and 120 million lines of code — equivalent to 32,500 person-years of work and $2 billion. All these achievements are the strength of the community!

Linux, for example, is 26 years old with 16.830,609 lines of code and 5,472 person-years.

The health of a community can make or break an open source project. The most important sign of a good community is that its members belong. A sense of belonging keeps people in the community.

Practice any experience you can think of

What does a successful open source project mean to us? The reward for contributing to open source is being able to learn a lot, be taught a lot, and exercise any experience you can think of.

Strengthen your existing skills: Whether it’s writing code, designing user interfaces, graphic design, writing documentation, or organizing events, if you have the desire to practice, you can always find a place in open source projects.
Hit it off: Open source projects tend to have a harmonious, enthusiastic community that keeps everyone together. In fact, it’s often the case in the open source community that deep friendships are formed by working together on open source, whether it’s during a technical conference or in a chat room.
Grow each other: Working with others on a shared project means explaining to others how you do it, and asking others how they do it. Learning from and teaching from each other is rewarding for everyone involved.
Word of mouth and reputation is your asset: By definition, all your work under open source is public, which means open source projects are a great place to show your strength.
Leadership and management is an art: Open source offers great opportunities to practice leadership and management skills, such as conflict resolution, organizing teams, and prioritizing work.
Don’t be too small: In the open source world, contributions don’t have to be made by people who have spent a lot of time and experience. Have you ever visited a website and found a typo and wished someone would fix it? Well, in an open source project, you just do it. Open source allows people to do things in a comfortable way, and that’s how the world should be experienced.

Open the door to the open source world

The trap of doctrine

Anyway, we’re gonna get it. We use it, store it or destroy it. Then the master is the new master, and the house will be the new house. But above all, one must be calm, brave, discerning and unselfish. People cannot become new people without being brought in, and literature and art cannot become new literature and art without being brought in. Bring doctrine — Lu Xun

This involves the differences between Chinese and Western cultures, intellectual property rights and other issues, which are not our main discussion this time.

The elephant in the room

Upstream prioritization has obvious benefits, such as increased product capacity, increased impact, finding the right people, cost savings, increased traffic, and access to the upper reaches of the supply chain.

But the reality is that few people to be involved in the Upstream community, only a few individuals and companies to do Upstream First, not we don’t have the coding ability or documentation, design, and so on some ability, but this matter is no one to do it, only do some people do less, you will find in the community of Daniel, Upstream First: Some companies encourage you to do Upstream First, but you can’t.

Elephant in the room – The social phenomenon of collective silence about obvious facts in both private and public life. You put an elephant in a room, you let a group of people in, and then people start talking, and everybody sees the elephant but everybody doesn’t say anything, and there’s a collective silence.

Making his mark

Static view of the problem, whether you are and open source software projects or doing things, or you do a commercial product based on open source software, or regard it as a third party, to do a thing, both from the upstream to cut out a branch, based on the branch have to do things, and the upstream community development projects are continually, But one thing we always do is, some time ago Linux released 4.4, AND I did something based on that, or I did something based on that, and these guys started doing it, and six months or a year later, what happened? Upstream has already sent two versions, it is already 5:00am, I found my own things do not have it all, or I also fixed the bug, I have to pay a very large price, because some interfaces have changed. It’s so common, you look around and it’s everywhere.

Tragedy of the Commons

To take or to give?

Common land as a resource or property has many owners, each of whom has the right to use it, but has no right to prevent others from using it, and each of them tends to overuse it, resulting in the exhaustion of resources. Over-deforested, over-fished fisheries and polluted rivers and air are all classic examples of the tragedy of the Commons. It is called a tragedy because everyone involved knows that resources will run dry due to overuse, but everyone feels powerless to stop the rot. And they all exacerbate the situation with a “grab a quick buck” mentality. It is an inevitable result that public goods are overused or occupied competitively because of the difficulty in defining property rights. This concept is often used in academic fields such as regional economics and cross-border resource management.

Not Just Coding!

If you’re new to open source, the process of contributing can be daunting. For example: How do you find the right project? What if you don’t know the code and you want to participate? What if you do something wrong?

Actually has no relation! All roads lead to Rome, and there are so many paths open source projects can take! Here are some practical tips to help you gain experience quickly.

You don’t have coding skills, and a common misconception about contributing to open source is that you have to submit code. In fact, while code is important, important parts of a project that don’t need to be coded are often overlooked. In open source projects code, documentation, topics for improvement, solutions, branding, etc., are all central to the success of a project. If you do this, it is a great contribution to the project, and it requires no coding at all!

Even if you’re a developer, non-code contributions are important to the project, especially to the rest of the community. Nurturing these relationships can open up opportunities to work on other parts of the project.

I’ll design the Logo

Hapi. Examples of js

What can I do?

Are you passionate about planning events?

Organize workshops or offline sharing for projects, as @fzamperin does for NodeSchool
Organize large meetings for the project (if it has one)
Help community members find suitable technical meetings and help competent members to submit draft presentations

Is there a design bias?

Rearrange the layout to improve the usability of the project
Conduct user research to reorganize and refine the project’s navigation or menu
Organize a style guide to help the project have a consistent visual design
Create T-shirt art or a new logo, as the contributors to Hapi.js did

Are you passionate about writing?

Write and improve project documentation
Can you give an example of how the project should be used
Write a press release for the project, or preach on a mailing list
Write tutorials for the project, as pYPA contributors do
The documentation of the translated project is in the local language

Do you like organizing events?

Link to duplicate questions and suggest new question tags to get things in order
Open up questions and suggest closing old ones, as @nzakas does for ESLint
Clarify recently opened issues to facilitate discussion

Have fun coding?

Find an open problem and solve it, like @Dianjin did for Leaflet
Think about whether you can help write a new feature
Automation project Setup
Improve tools and tests

Passionate about helping others?

Answer questions about your project, such as on Stack Overflow (like this Postgres example) or reddit
Answer open questions for people
Help ease discussion boards or dialogue channels
Do you like helping others with your coding?
Review code for other people’s submissions
Write a tutorial for how to leverage the project
Mentor other contributors, as @ereichert does for @BronzDoc. Oh, project Rust

Different fields? Although the word “open source” is used by default to mean open source software, it doesn’t necessarily mean that. Open source can be a fancy word for anything, not just software. Such as books, recipes, lists, and any project class that can be open source.

For example:

@sindresorhus created the “surprise” list
@H5BP maintains interview questions for front-end developers
@StuartLynn and @nicole-a-Tesla produced a collection of interesting facts about puffins

Even if you’re a software developer, you can write documentation to help new entrants. The projects that seem intimidating aren’t about writing code. You have to challenge yourself as a developer, but you can gain confidence and experience in doing so.

The fit is the best

Identity and community concept
Community culture and rules
Respect for others

self-image

An excellent community operation concept should be contribution, co-governance and co-prosperity, which is exactly the concept of the front-end technology system of the large platform. If the open source community is to grow, it needs to call on more people to contribute and participate in it, and more people of insight to work together to achieve a common prosperity of open source. How to achieve such a great goal, not by me, not by you, by all of us. Selfishness, autonomy and freedom are prerequisites.

Selfish, here is a neutral word, that is, to meet their own needs as the premise, to contribute more. While satisfying their own needs, many open source contributors behave in this way; On the other hand, the premise of co-governance is autonomy. Only when each member of the community manages his or her own community well and does not rely on the party, can he or she spare power to cooperate in co-governance. Otherwise, they will not be able to manage their own affairs well, so how can they participate in cooperation? Only freedom can finally co-prosperity, everyone can enjoy the right to freedom in the community, not suppressed and not closed, but also respect everyone’s right to free expression and free participation, only in this way can more people in the community be willing to contribute to it, more people are willing to work together to jointly govern, and the situation of co-prosperity will finally come.

Community culture and rules

Every open source community is different.

Having been in an open source project for years means that you are only intimately familiar with it. If you switch to a different project, you may find that the vocabulary, the idiom, the way of communication have all changed.

However, many open source projects follow a similar organizational structure. Understanding the different community roles and the overall process is a great way to get started quickly on new projects.

A typical open source project will have the following types of people:

Author: the founder or founding organization of the project

Attribution: The administrator of the repository or organization (not necessarily the same person as the author)

Maintainers: contributors who are responsible for the future direction of the project and the management of the organization (they are often also the authors or owners of the project).

Contributors: As long as they contribute to the project, count.

Community members: people who work on practical projects. They may be active discussants or provide ideas for the direction of the project.

For a larger project, there may be a sub-community, or different groups for different tasks, such as tool groups, triage, community affairs, and event organizations. Go straight to the project to the Web site, find the “Team” page, or check the governance documentation for similar information.

Proper open source projects usually have a documentation, which is usually listed in the top-level directory of the code repository.

License agreement: According to the definition of open source software, every open source project must have an open source license. Think of it this way: if a project is open source but does not have any licensing agreements, it is not open source.

README: A README is an introductory document that welcomes people to their community for the first time, usually explaining why a project is useful, why it was initiated, and how to get started quickly.

Contribute: READMES helps people get to know the project, and contribute to this document helps people know how to contribute to the project. It explains what types of contributors are needed for the current project and what the community is for the process. Not all projects will have this file, and it’s a way of showing how contributor friendly the project is.

Code of Conduct: As the name implies, this is the etiquette, speaking style, and behavior of participating in the community, which helps to create a friendly atmosphere. Not all projects write code of conduct documents, which in some way show how friendly the project is to the contributors.

Additional documentation: Some projects may have additional documentation, such as tutorials, guides, or governance rules, as is common in large projects.

In addition, open source projects use the following tools to organize discussions, and reading these archives can be very helpful in understanding what the community is thinking and how it works.

Problem tracking: This is where people discuss project-related issues.

Pull requests: Review code and related problem discussions.

Forums or mailing lists: Some projects have conversational themes (e.g. “How do I… “Or” What do you think about… “Instead of Bug reports or feature requests). However, there are some projects that discuss all practical issues of tracking.

Live Chat: Some projects use chat channels (such as Slack or IRC) for casual conversation, collaboration, and quick communication.

Commit activity when the project is received: The commit activity is confirmed on the trunk. Open source projects hosted on GitHub, you can see this information on the repository home page.

When was the last submission?
How many contributors does the project currently have?
Do people submit it frequently? (On GitHub, click “Commits” in the top column.)

Next, look at the number of issues in the project.

How many issues are currently open?
Does the maintainer of the project respond quickly to an open issue?
Are there any active issues?
Are the issues all recent?
Are there any closed issues? (On GitHub, click the “closed” TAB to see all closed issues.)

Let’s also look at the PR situation.

How many PR’s are open right now?
Does the maintainer respond quickly when a PR is submitted?
Is there an active discussion PR?
Are they all recent RP’s?
How many PR mergers have taken place recently? (On GitHub, click the “Closed” TAB on the RP page to view closed tabs.)

The popularity of the project

A project’s friendliness and popularity means it is more likely to attract new contributors.
In the issue question, was the maintainer’s answer helpful?
Are people friendly in issue discussions, online chat rooms, forums?
Has PR been reviewed?
Do maintainers say “thank you” to people who contribute?

An open source agreement to be aware of

http://choosealicense.online/

Respect for others

I’ll start with two short stories,

Lu hou birds

In the past, seabirds stopped in the suburbs of Lu, And The Emperor of Lu began in the temple. Play “Nine shao” thought music, with too strong thought meal. The bird would glare at sorrow and sorrow, dare not eat a luan or drink a cup, and die in three days. This raises birds by oneself also, does not raise birds by birds also. From “Zhuangzi, Outer Chapter, Zhi Le”

The translation

Once upon a time, a seabird was staying on the outskirts of the capital of the state of Lu. The king of Lu sent a carriage to meet it, toasted it in the ancestral temple, played the nine-Shao poem to make it happy, and prepared meat from cows, sheep and pigs for its food. So the seabird became dazzled and sad. He dared not eat a piece of meat or drink a cup of wine. In three days he died. This is to use their own way of life to raise birds, not the way to raise birds to raise birds ah!

There are great differences between people and things. What you think is best may be perceived as bad, or even worst. Measuring another by one’s own bushel is sometimes wrong. Subjective assumptions often lead to failure. You should respect the original rules of things. You should not just do what you want. If you blindly take things for granted, you will surely fail.

I contribute to open source

You’ve found a project you love, and you’re ready to contribute. All right! Here’s how you can contribute in the right posture.

The Art of questions

Whether you’re making a one-time contribution or joining the community permanently, communicating with others is a skill you need to develop to thrive in the open source community.

Before you start an ISSE or PR, or ask a question in a chat room, keep the following tips in mind to make your work more efficient.

Collect and then give context 😢 “X is wrong! Please fix it.” 😇 “X doesn’t work when I’m doing Y”
Be prepared 😢 “How do I do X?” 😇 “I’m not sure how X is implemented, I looked up the related help documentation and found nothing.”
😢 “I was driving down the highway one day, filling up at a gas station, and it occurred to me that we should do this, but before I go any further, LET me show you…” 😇 “I would love to write a tutorial on the API.”
OPEN 😢 (email) “Hello, sorry for sending this, but I really hope you can take a look at the PR I submitted.” 😇 (comment) “@Maintainer hello! What do we do with this PR?”
Bold but cautious 😢 “Why don’t you fix my problems? Isn’t that your project?” 😇 “Thank you for checking this error, I did what you suggested, and this is the output.”
Respect the community’s decision 😢 “Why don’t you support my use case? This is unacceptable!” 😇 “I’m disappointed that you can’t support my use case, but your explanation only works for a small number of users, and I understand why. Thank you for listening.”

Create Issue

You should create an issue when:

Report errors that you can’t fix yourself
Discuss an advanced topic or idea (e.g. Community, vision, policy, etc.)
An idea for a new feature or other project to be implemented

Some practical skills in issue communication:

If you happen to see an open issue that you want to address, add a comment and tell others that you will be responsible for it. In this way, others can avoid duplication of work.
If an issue has been open for a long time, it could be that someone is working on it, or it’s already been resolved, so please add a comment as well, and it’s best to confirm before you start working on it.
If you create an issue but later resolve it yourself, add a comment, let others know, and then close the issue. The record itself is a contribution to the community.

Create a pull request

Make sure you use PR when:

Submit patches (for example, to correct typos, broken links, or other obvious errors)
Start a task that someone else has requested or discussed in the past in issue

A PR doesn’t mean the job is done. It usually starts a PR as early as possible so that others can watch it or give feedback to the author. Just mark the subtitle as “WIP” (in progress). Authors can add many comments later.

If this is your first time submitting a PR. Check out the PR Made documentation, a public resource written by @KentcDodds for people starting PR for the first time.

Github operation process

If the project is hosted on GitHub, here are our tips for submitting your RP:

Fork the repository and clone it locally, configuring “upstream” in the local repository to be the remote repository. This way you can stay in sync with “upstream” when you submit your PR, reducing conflict resolution time. (For more on synchronization, see here.)
Create a branch for your own editing.
Refer to any related issues or support documentation in your RP (e.g. “Watches #37.”) includes before and after snapshots if your do-overs include different HTML/CSS Drag the corresponding image in your PR.
Test your changes! If the test case exists, run it to override your changes, if not, create the corresponding use case. Whether tests exist or not, make sure your changes don’t break existing projects.
Do your best to be consistent with the existing style of the project. This means using indentation, semicolons, and comments that are likely to be very different from your own style, but bear with it to save your maintainer’s effort and to make it easier for others to understand and maintain.

# # #

Freedom, openness, collaboration and sharing are the spirit of open source. It is no longer an era of one person, and no hero or genius can do the platform well alone. Our big platform is not one person’s big platform, it is everyone’s big platform. We are to continue to explore and practice, to achieve the sharing, construction and dissemination of front-end technology system.

Finally, give you a word: open source is knowledge, determine the value of us!