Original link: https://notes.ljl.li/start-oss/
Friends who may know my interview habits know that my last question must be:
Introduce three of your favorite open source libraries.
What is asked is the interviewer’s sensitivity to open source and enthusiasm for learning. According to the content of the answer (whether it is common or the reason for concern), I can roughly understand the other party’s learning preferences as a more important reference.
I’m an avid open source enthusiast. I’ve always wanted to write an article about open source, but I haven’t been able to find a good opportunity. It so happened that recently, my GitHub followers broke through 1k and entered the top500 in China, so I thought it was time to write something.
It’s just my personal experience and ideas, it may not be mature, welcome to correct me. By the way, if you see this, please follow my GitHub and read it together: https://github.com/ddiu8081.
What is open source and what is contribution?
Please allow me to babble a few words first, starting from the concept. Open source, as the name implies, is open source code, which allows anyone to view, modify, and distribute source code for almost any purpose. Contribution refers to the behavior of making valuable improvements to open source projects.
Whether it is submitting code or simply submitting an issue, it is a contribution to the project and can strengthen the power of the open source project.
The opportunity to create a project: from toys to 7k stars
In fact, I am still in a very shallow field of open source. I have not deeply participated in or contributed to large-scale projects. I have only created and maintained some side projects, so I may not be able to explain the open source field comprehensively. But it happened that in these two months, one of my side projects gained some attention, accumulatively gained 7k stars within 3 months, and 31 contributors made their own contributions to the project. So with this project, let’s talk about the beginning of an open source project – how to create a project.
First, let me introduce this project: ddiu8081/chatgpt-demo (currently created and transferred to the anse-app organization). This is a WebUI of the OpenAI gpt-3.5 interface, which provides a set of minimalist front-end + back-end implementations, allowing users to obtain a ChatGPT-like experience in a mainland network environment, and can deploy to any server with one click.
After this project was made, it gained a completely unexpected attention. The number of stars on GitHub exceeded 1,000 on the first day, and the demo site provided also reached 100,000 queries per day. I also received a huge bill of $8700 from OpenAI for this:
As for why I thought of creating this project, it can be seen from its bohemian name that it was originally made as a toy for personal use. On a peaceful morning in early March, I swiped my phone and suddenly discovered that OpenAI released the ChatGPT API. Because I have briefly experienced ChatGPT before, I know that its experience for mainland China is not very good-difficult to register, difficult to log in, slow to reply, and more than half of the failure rate. Therefore, if there is an API, these problems can actually be solved. Isn’t this a useful personal chat assistant?
So on the day the API was released, I spent two hours making the chatgpt-demo project, and tied a domain name for my own use—and then sent it to the fan group and V2EX for netizens to play. Then it becomes like above.
Therefore, I think that maybe starting a project does not need any very formal reason, nor does it need to be a serious project: it can be a wheel for practice, a toy, or even a recipe ( Anduin2017/HowToCook ). But it is best to follow the direction of your own interests, because interest is the best driving force.
Maintenance of open source projects
Although I have limited experience in maintaining open source projects as a participant, I can probably talk about how to maintain open source projects from the perspective of a project manager:
positive response
After an open source project reaches a certain scale, it is often accompanied by many issues or PRs. Most of the time, I can receive hundreds of notifications about the project in a day.
Most of the issues are to submit bugs for the project, and some are Feature Requests, which suggest new features for the project.
I found this project in the vast repo sea, which is a kind of fate in itself. You may wish to express your gratitude in the reply column and thank the other party for submitting the questions.
Of course, there will be requests that you want to refuse, which are mostly in PR. Most of the code submitted by contributors has problems with the format, the impact is too large, or the content of the changes deviates from their own plans for the project. In this regard, I suggest still thanking the other party for their efforts, and then pointing out the points that you don’t agree with.
But issues are not always friendly
Among the issues submitted by users, there are indeed some issues of poor quality, such as:
- An issue titled “Why it doesn’t work” without any information attached;
- Advertise in issue;
- Do not describe the problem in the issue, but directly start diss or meaningless debate.
In order to avoid unpleasant feelings brought by others, or even the phenomenon of bad money driving out good money, it is necessary to reply or close in time to maintain the health of the community.
Create an issue template
In the early days of the project, there was no specification for issue submission, and users could submit any content. But for a bug report, if there is a lack of information, it is difficult to locate the problem, and it becomes an invalid issue.
In order to reduce invalid issues, it is a good way to create issue templates.
Still take the issue creation page of anse-app/anse ( https://github.com/anse-app/anse/issues/new/choose ) as an example. I set up three submission entries: Bug report, Feature request, and Typo fix to represent Bug submission, feature request, and grammatical content repair respectively. In addition, some possible links (project documents, roadmap, discussion forum) are listed below for diversion.
Take the bug report as an example. First, I listed a few must-read items:
- Confirm that you are using the latest version, and make sure that you are not reporting a problem that has been fixed;
- Confirm that this question has not been raised by others to avoid repeated issues;
- Communicate in English, which allows more people to participate in the project and contribute to the issue.
Then, additional information such as the system environment and browser environment need to be filled in the form to assist the maintainer in locating the problem.
In this way, by adding templates, the quality of issues can be greatly improved.
Provide contribution guidelines
When passers-by are interested in contributing to the project, a good guide is necessary – after all, it is difficult for casual contributors to be familiar with the entire project at once. Therefore, in open source projects, it is recommended to have a document section called CONTRIBUTING to welcome new contributors and explain to them the main structure of the code, how to run and modify the code.
Keep Communication Open
I have received a lot of emails, all privately asking questions about the project. This is actually not conducive to information sharing, and may lead to information gaps between different users. For this reason, my approach is not to answer project questions asked through private chats, but to guide the other party to post issues where everyone can see them.
The spirit of open source is collaboration
Don’t fix the bug yourself just yet. Strange as it may sound, simple, non-urgent bugs are good candidates for getting others involved in the contributing team.
To this end, like many open source projects, I also added a checkbox to the issue template of the anse-app/anse project:
I am willing to submit a pull request for this issue.
I am willing to submit pr for this issue.
This can actually lead the author of the issue to think: Can this bug be fixed by itself, and can the feature be completed by itself? That’s the transition from issue submitter → code contributor, if you will. Of course other users can choose to contribute to it if this box is not checked.
If there are some particularly active contributors during this period, I may choose to invite them to become members of the project, so as to be able to participate more deeply in the decision-making of the project.
Let everyone feel that they are part of the project. I think this is the collaborative spirit of open source.
What can be gained by doing open source
The open source guide is over, let’s talk about what I have gained from the maintenance of open source projects.
Open source is also a kind of learning
By maintaining open source projects, I have received hundreds of Pull Requests and seen hundreds of people’s modifications to my projects. From their code submissions, we can indeed find some things worth learning, such as the use of a certain API, and a refactoring that can greatly reduce the logic complexity. Some of these changes are things I didn’t know before, but after reading other people’s code, I can indeed learn some knowledge.
build influence
Speaking of the time I have been deeply involved in open source, it has only been more than a year. At that time, my Followers were less than 100, and it was difficult for the project to gain attention. For more than a year, as Followers has slowly increased to the current 1.2k, I can feel that the influence has improved to a certain extent—for example, I found a good unpopular project and clicked the star. After a while, I looked back and found that The number of stars has increased a lot, in fact, I am more happy to see such scenes.
During this period, I also received the attention of Anthony Fu, an open source idol, which was very pleasantly surprised.
Connect with like-minded friends
Although the project I maintain has not established a chat community such as Discord, but in places such as Issue and Discussions, you can see many people communicating in a friendly manner and sharing their ideas with each other.
Although some of these proposals will be rejected by me, it is undeniable that every participant is working hard to make the project better.
The art of learning management
In the beginning, when I received the Pull Request for the project, I was quite at a loss—I was not willing to accept it, but I felt bad about rejecting it. As more and more PRs are received, I feel that I have been able to close them freely; in addition to making decisions, there are other improvements in leadership and personal abilities.
Finally, something you might care about
Q: Did it really cost $8,700?
A: Yes, but OpenAI pays for me. Because the interface has only been launched for a day or two, maybe the OpenAI billing gateway has a delay failure, and the real-time consumption amount has lagged for several days, so the maximum amount I set did not stop it. OpenAI used the $8,000 as a credit afterwards, so I didn’t actually pay the money.
Reference
This article is transferred from: https://notes.ljl.li/start-oss/
This site is only for collection, and the copyright belongs to the original author.