Hello everyone, my name is zero one . Recently, I saw a surprising news in the community. Nearly 20k Star 's build tool library Snowpack author Fred K.Schott (referred to as Fred in the text) said that he has no energy to maintain snowpack, and its usage Downloads are beginning to show a downward trend. Fred also reviewed Snowpack's life, reflected, summarized, and used these experiences to devote himself to another new project Astro , and Sonwpack intends to hand over to the community to maintain . This... Did the author say that he would not do it?
Translation: Seriously, I'm not sure what will happen after Snowpack. At the end of last year, maintaining snowpack was overworked, and now there is no energy to maintain it. Snowpack usage and downloads have begun to show a downward trend, and the community has become calm.
So maybe it makes sense to slow things down. We would like to ask if anyone in our community is willing to participate in long-term maintenance. But it will take some time for new contributors to get started, and we don’t seem to be able to find it yet...
To be honest, it is a pity, but there is no way, open source itself is not easy. But Snowpack is also doing well. Think about the fact that under a large project built on webpack, the project startup time can be exaggerated and can even exceed 100s, and the update speed is not timely. When the browser supports the ESM import module to load, we will not node_modules ) needs to be processed during construction. All modular loading is handed over to the browser to achieve native tree-shaking. At the same time, single-file modification in the project can also achieve single-file reload , The efficiency of this development and construction is visible to the naked eye! Snowpack is one of the better implementations of bundleless!
Back to the topic! Let's get to know and learn about Fred's experience in making Snowpack open source library!
Successful experience in doing open source
Snowpack can also be regarded as a relatively successful open source library, which can be reflected in the three dimensions of user volume, download volume, and Star. After all, 100w+ downloads and nearly 20k Star not just casual. If he did, Fred also summarized his successful experience , and hope to help everyone!
1. Pain-driven, clear direction
Snowpack was originally made by Fred in the work of Google’s Polymer team to replace the HTML imports specification. Later it was extended to "Why do npm packages need to be packaged with webpack to run in the browser, and cannot be run separately? What about the browser?” The problem of "npm package runs alone in the browser" , and this is the Snowpack that follows
So this library started with Fred's questioning and thinking about the status quo. This allows him to clarify the direction of the library and also know what needs to be done in the future! If an open source author creates a library inexplicably, and there is no clear direction for the library, then in the long run, even if it is open sourced, users or developers are confused, this library is destined to not go far!
2. Act fast and act decisively
After clarifying the general direction of a library, you must continue to improve the large and small functions. In the process, you don't know which codes and which functions are important, and whether they will be discarded in the future. Based on this, at the beginning of the project, does not have to worry too much about , has an idea and just do it directly , even if the function you write will be deleted later, even if the code structure you write is a little messy, it’s fine. Question, not a big deal for follow-up improvement ! (It is said that Snowpack has no code structure at all at first, the whole process is a index.js stud)
Moreover, Snowpack’s original core goal is not to package business code, but to directly use the browser’s native ES Module capabilities. Therefore, Fred has a layer of encapsulation based on rollup, and will use the library to generate the corresponding ESM module files, and import path with the generated ESM module file
It is said that will be used Sonwpack, saving Fred many weeks, even many months!
Of course, in response to the , the slogan of 1614c2157ebc46, Fred did not even write unit tests in the early days of Snowpack, not because he did not know to write a single test, but he felt that he was only in the early stages of the project and was not sure about this project. Whether it is useful and whether it will be accepted by everyone, plus writing a single test itself is a very time-consuming task. If you work hard to write the single test in addition to completing various functions in the early stage, if you end up with your own project, it is of no use , Unable to land or not adopted by everyone, then a lot of time wasted in the early stage. Fred believes that this situation is very troublesome. He would rather wait for the project to be used by many users before making up the technical debt he owes. !
summarize:
- It’s okay if the code is bad, act first, realize the function is the most important, and then optimize the code.
- Be sure and focus on what you are going to do
- You can use better open source libraries or tools to improve development efficiency
- The single test can be skipped in the early stage, and the single test can be rewritten when it is really needed in the later stage.
3. Quickly fix bugs
Every open source library should have more or less bugs in the initial stage of use, especially when someone tries to use your released library, after encountering a bug, it will definitely give you a big issue. At this time, as an open source library The author should solve this issue as quickly as possible. After all, they are one of the few users in the initial stage of your project, let alone find the bug for you. If even this user's service is not good, let alone After saying that thousands of developers use your library
So if you do open source, you want to do business again. The batch of users who initially used your open source library (not yet fully mature) are your resources for cold start. Only when they are served can you have a chance to succeed in cold start and become widely known.
One of the reasons for Babel's success is to fix bugs and release new versions quickly. It is usually fixed and released within a few minutes after the bug is reported. This is crucial when there are not many early users. Users will feel that the maintainer of this library is very efficient, and if they encounter a bug in time, they will not complain that there are so many bugs in this library and give up using it.
4. Promotion
Promotion and publicity replaced by a "headache" word called marketing , maybe everyone will think of the marketing account, in fact, it is not for everyone to do some "sordid" promotion in order to promote their open source library, or even Pulling on other libraries to raise your own Cooha. This malicious marketing will make people very offensive. No matter how good your library is, your reputation will not be much better.
It's a headache, I have worked so hard to write a library, and I have to work hard to promote it. If it is not promoted, no one will use it, and no one even knows it!
So what should we do?
You can share it with your friends and colleagues, or ask them to give you some suggestions. If you are lucky, there are users who try your library early, then they can also give you a lot of suggestions and even help you promote it!
If you have the opportunity to share your project with more users in the future, then you can introduce to them and communicate with them in some interesting ways. For example, give you a few lively and interesting introductions to your project. Promotional videos , tell some short stories about you and your project , write some technical blogs to directly or indirectly introduce your project etc.
After Snowpack had a certain user base, Fred spent a lot of time writing a blog, which introduced the reason for the birth of Snowpack and anything he had with the project. At that time, it was very popular with this article alone, and In the following year, it was shared and quoted by many users. In short, the user growth is very fast! ! I think Fred’s article is more deliberate, so that everyone can empathize~
In fact, the author of an open source library in China has done a good job in promotion. He is the author of H5-dooring Xu Xiaoxi. In the past few years, he has been promoting the open source library precipitated on LowCode in many communities. The way to write technical articles is to promote and publicize. After reading the article, everyone has learned the technical implementation of the LowCode platform, and also knows that there is such an excellent open source library. On the other hand, everyone should have more trust in him. After all, they can output technical articles and show them to everyone, and communicate and discuss together~ This is also a virtuous circle.
5. Listen to users
Now that they all support freedom of speech, you will definitely encounter a lot of comments in the process of promoting your open source library, such as:
- Didn't the xxx library have implemented your function long ago? Is it interesting to reinvent the wheel?
- Give the author a suggestion, I feel that the realization of the xxx function can be replaced by the xxx solution, which is better
- There are so many bugs in this library, it is better to use xxxx
- This feature is awesome! Hope to maintain it forever
- ....
As you can see, there are good and bad comments. You also have the ability to distinguish between different feedbacks. Don't be satisfied with the moment by being dazzled by a lot of praise, and don't be let down by some critical words. When you are praised, you should be more motivated to make open source libraries better. When you receive well-intentioned suggestions, you should also maintain a humble attitude to accept; when you are criticized, you must first reflect on whether you are your own open source library. The publicity is not in place and users have misunderstood your library. Do you need to rewrite README.md or introduce it in the community? Secondly, you should consider whether the person who criticizes you is idle and nothing to step on your project (commonly known as the keyboard man), then you can ignore it, try to ignore it, and spend more energy to find it more constructive Meaningful evaluation!
In short, it is to listen to the voices of users, after all, they are the people who are actually implementing your open source library!
Summary of open source errors
Of course, Snowpack also has some bad points, otherwise Fred will not have the energy to maintain it. So when maintaining such a large open source project, what conclusion did Fred draw in his summary and reflection?
1. Using Dogfooding Method
Dogfooding: is explained by Wikipedia, Dogfooding is a practice of using its own products or services to support internal testing. It can control the quality of products in advance and be fully confident and formal online
To give a simple example, Facebook (abbreviated as FB in the text) has open sourced React, and many of its internal applications are also developed based on React. If React adds a feature or fixes a bug, in addition to using a single test to check, FB will also You can apply the modified React to your own internal applications and verify the stability of React functions in real online projects. It must be more comprehensive than just testing in a development environment. After the modified React has been used in its own project for a period of time and there are basically no problems, FB can confidently believe that the quality of React is highly guaranteed and open to other developers.
In fact, Fred did not apply his own open source library to his own internal projects as well as FB in the maintenance of Snowpack, so there is no way to do a good quality assurance before the new features of Snowpack are released, Fred Instead, the approach is to communicate and discuss with users before developing new features of Snowpack.
Fred now recalls that he really should have adopted the Dogfooding method in exchange for more online functional testing and quality assurance for his open source library.
2. Guarantee quality and quantity, understand users
In the previous article, Fred’s successful experience mentioned that he served the first batch of Snowpack users as much as possible at the beginning of the project. A certain function implemented at that time was recognized by the initial users, but more and more people used it. The more, most of them think this feature is bad, and even think it should be discarded. There is a process of changing user needs, so in any link of the entire project maintenance, you have to understand user feedback, so as to better promote the development of the project
In the initial stage of an open source library, there may be many large and small bugs, which are all justifiable. After all, it is just the beginning and not many people use it, so it will not cause hundreds of bug feedbacks. Or user complaints. And as the project gets on the right track and becomes more mature, more and more people are using it. What users expect most is that the library has fewer bugs and more stable functions, so what an open source should do is to improve open source The quality of the library guarantees the most basic user experience!
3. Collect feedback and actively resolve
Not everyone will give you feedback. Put yourself in it and think about it. If you encounter a problem when using some open source library, you will go to Baidu to search for a solution to the problem. If you don’t find it, you will go to the official documentation of this library or Github issues. Is there anything similar? Answer, if you don’t have it anymore, you probably don’t want to use this library. You may still say in your heart: This library is really LJ, there are so many questions, if you are a little bit patient, you will give him an issue, eager for the author. Reply, eager for the question to be answered, but if you do not get a response too late, the end result is that you turn around and find another mature open source library that can replace or even surpass it.
According to Fred, the Svelte team mentioned in a blog that they are very interested in Snowpack, which means that Snowpack may be used by their team (user +1). Fred is also very happy, but Later, Fred discovered that SvelteKit , they had replaced the Snowpack with Vite , which can achieve the same function. Later, after learning about it, he learned that the Svelte team was not very satisfied with Snowpack, and followed the example I just gave. They did not give feedback to Fred, because they may have no time and patience for various reasons to go through this complete link of "feedback -> waiting to be solved -> problem solved". At this time, there is a separate library. It can meet their needs, and there is basically no problem. Isn't that beautiful?
Fred later reflected that he felt that Snowpack did a good job in communicating with users in the early days, but as the user group became larger and larger, there was no strong sense of interaction with users, and some of them would naturally be streamed. user. Fred later learned that the Svelte team often encountered problems when using Snowpack, but it was too late when Fred received their feedback because they had given up on Snowpack.
In this regard, Fred himself also summed up an experience: as the creator of the open source library, must have a good feedback channel and maintain strong interaction with users. Don't just wait for users to give you feedback on the problem, you must also actively collect user feedback and solve the problem proactively and quickly
4. Continuous output, continuous improvement
The birth of an open source library is definitely to solve a certain problem, but the problem cannot be solved, and the functions of the first version are generally relatively simple, so the open source library must always be maintained. And doing open source itself is not an easy task, because once the user community is large, you will receive countless issues every day, and there are many problems and bugs waiting for you to solve. Fortunately, the community is still very friendly and active. There will be students who are willing to find problems and submit feedback. Even students with good abilities will submit a pr to contribute some code. This is the best way to open source.
As an open source project creator, what you should do more is to take the initiative to solve these user feedback problems, carefully review the code submitted by others, and at the same time think about what else your project can optimize and improve. In short, To continue to improve the open source project , your users can also see from your efficiency that you are a very good and responsible person (Wow! This author has submitted more than a dozen code times a day! I have 2 hours The bug of the premise is fixed so quickly! The efficiency is really high!), then the trust generated in you can also be mapped to the open source project you are doing
It seems that open source is very time-consuming to hear here! Do you want to give up your current job and do open source full-time? Not really! Because there are still few people who can really support themselves by doing open source full-time, most of them do it part-time or even part-time. Of course, it’s okay to do open source part-time. You can try to spend a few hours a week or a few days a month to maintain it. Your open source project is better than what you leave it alone
In fact, the friends in the community can also feel the degree of your investment in open source projects (this library was submitted half a year ago, and more than 500 issues have not been resolved! I don't know if it is reliable!), you did not try Continue to maintain, then the entire community will calm down. This is the biggest problem for open source. Fred said that he has seen many large open source projects often make such mistakes. You can't just rely on your friends in the community to give you pr to maintain open source projects, right?
5. Build a community
Needless to say, everyone can appreciate this. Building an exchange community for your own open source project is the same as creating a customer VX group for merchants. It shortens the link between "merchants" and "users", and at the same time provides a platform for users with functional purposes to communicate and discuss. They can Actively express your ideas, you can also help each other, you can also get valuable feedback from the community
6. Many people are powerful
This last point may also be one of the biggest reasons why Fred has no energy to continue to maintain Snowpack.
Contributors Snowpack. At the time of writing this article, there are a total of 402 . It can be seen that the community partners are very active and are willing to help maintain this project together. Looking at this trend, Snowpack should be doing more and more. All right?
But Fred doesn't think so! he always wanted to be alone full safeguard Snowpack, do not accept Larger Contributions , because of his short-term thinking told him: he was a man to do, may be more efficient (after all, do not need people to cooperate, to avoid a lot of cooperation The problem). really! During that time, Fred output a lot of things, and the efficiency is really high! But in the long run, the problem will only gradually be exposed. Fred output large amounts of content is based on hurry completion , skip the code checks under the premise of, come out to mix always has, always do so in accordance with this approach, because sooner or later the code quality is not high, the structure of chaos Wait for the problem and the maintenance cost becomes larger
I hurried to take a look at Snowpack’s Larger Contributions . It’s really not many, including Fred himself, there are 2 in total!
To sum up, after an open source project gets bigger, you can’t just do it alone. It’s wise to find interested and capable partners to form a team to build together. After all, open source is not just about writing code, but there are many things to do, for example : Add new features, fix bugs, collect and solve user problems, publicize and promote, write official documents, etc. Finally, with the help of the team and the enthusiastic friends of the community, the progress of the open source project will surely be promoted smoothly. If the subsequent open source project makes a profit Now, as the creator, you can also give some Money to the friends in the team on a regular basis. After all, no one is generating power for love~
chat
The article mentioned that SvelteKit gave up Snowpack and chose to use Vite. Would anyone think that Vite killed Snowpack? In fact, it is not who killed who. Fred also saw many problems when he was doing open source during his life review of Snowpack. I can only say that there is no other big man who has experience in doing open source~
Let’s talk about Vite in detail. You can learn from Vite’s official document that Vite draws on Snowpack v1's dependency pre-build function, so from this point, the two libraries are very similar, so many bigwigs in the community I often write comparative articles about these two libraries. Why was Vite born? It is said that Youda found that this library did not support HMR very well when using Snowpack v1, so he made a Vite and provided HMR based on native ESM. Similarly, Snowpack v2 also borrowed from this feature of Vite. Achieved
Fred also very generously praised Vite for doing very well, and said that he would also migrate his project Astro from Snowpack to Vite in the future.
Translation: At the same time, Vite is developing rapidly. It is commendable that they have done a lot of things very well. The better thing is that these two tools are very similar and easy to switch between. Even afterwards Astro will try to migrate from Snowpack to Vite.
really! From the perspective of Vite, review all the chapters just mentioned in this article. Vite does a very good job. development efficiency, problem and bug fix speed, promotion, perfect documentation (both in both Chinese and English), continuous output, quality assurance amount, expanding ecological etc., will be no wonder Fred praise ~ to the point of a particularly great praise!
Summarize
After reading Fred's open source summary (the boss is very humble), I have benefited a lot, and I hope to inspire you who are doing open source in the future or now~
I have mixed up a lot of personal thoughts in the article, and I have incorporated Fred's summary into this article a little bit. If you want to read the original text, I will put the link here~
If you have any questions, please point them out 👏🏻! If you have any ideas, you can also leave a message in the comment area~ Welcome to discuss!
I am zero one , sharing technology, not just the front end!
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用。你还可以使用@来通知其他用户。