Hello, everyone, I am zero one. One of the most surprising things I’ve seen in the community recently is that Fred K.Schott, author of the nearly 20K Star build library Snowpack, said that he no longer has the energy to maintain Snowpack and that usage and downloads have started to decline. Fred also took the opportunity to reflect on Snowpack’s life, reflect on it, summarize it, and use the lessons to invest in another new project, Astro, which Sonwpack plans to hand over to the community. This is… Does the author say to stop doing it?

To be honest, I’m not sure what will happen after Snowpack. At the end of last year, maintenance snowpack was overworked and now I don’t have the energy to do it. Snowpack usage and downloads have started to decline, and the community has calmed down.

So maybe it makes sense to slow things down a little bit. We would like to ask if anyone in our community is willing to participate in long-term maintenance. But new contributors will take some time to get started, and we can’t seem to find…. yet

Honestly, it’s a shame, but I can’t help it. Open source itself is not easy. However, Snowpack does a good job, considering that in large webpack-based projects, the project startup time is exaggerated and even more than 100s, the update speed is not timely, and when the browser supports the ESM import module loading, We don’t need to deal with the relationship between modules (including node_modules) at build time, all the modular loading is handed over to the browser, realizing the native tree-shaking, at the same time, the modification of single files in the project can also be reloaded, which makes the efficiency of the development build visible to the eye! Snowpack is one of the better bundleless implementations!

Back to business! Learn more about Fred’s experience with Snowpack.

Successful experience of open source

Snowpack is one of the most successful open source libraries in terms of users, downloads, and Star. After all, it is not easy to achieve 100W + downloads and nearly 20K Star. Fred also summarized his successful experience to achieve this level, hoping to help you!

1. Pain point drive, clear direction

Snowpack was originally developed by Fred on Google’s Polymer team as a build tool to replace the HTML Imports specification. Later, it was explained as “Why do NPM packages need to be packaged with WebPack to run in the browser and not run in the browser alone?” Fred began experimenting with the possibility of “NPM packages running in the browser alone,” which led to Snowpack

So this library started with Fred’s questioning and thinking about the current situation, which allowed him to know the direction of the library and what he needed to do in the future! If an open source author creates a library without any clear direction for the library, then in the long run, even if open source, users and developers will be confused, and the library will not go far!

2. Act quickly and act decisively

Once you know what the general direction of a library is, you start refining features, big and small, without knowing which code and features are important and whether they will be deprecated later. Based on this, there is no need to worry too much at the beginning of the project, just go ahead and do it, even if the features you write will be deleted later, even if the structure of the code you write is a bit messy, that’s ok, it’s not a big deal to improve later! (It is said that Snowpack originally had no code structure at all and was an index.js boha throughout.)

And Snowpack’s original core goal was not to package business code, but to use the browser’s native ES Module capabilities directly, so Fred encapsulated it based on rollup, using the library to generate the corresponding ESM Module files, and replacing the import path with the generated ESM Module files

It is said that Rollup in Sonwpack saved Fred many weeks, even months!

Corresponding rapid action, of course, in order to Fred at the beginning of the Snowpack even didn’t write unit tests, not because he doesn’t know to write a single test, but he felt he was only in the early stages of the project, also not sure whether the project is useful, whether can be accepted, and write a single measurement itself is a very time consuming, If early at try very hard to complete each function and try to write the single measurement, if at the end of the project is not what use, cannot fall to the ground was adopted or not, the early waste of time to many, many, Fred think this kind of situation is very headache, he would rather wait to project is used by many users, the technology to catch up on his owe debts!

To sum up:

  • Code to write bad nothing, the first action, the function of the most important, can optimize the subsequent code
  • Be sure and focus on what you have to do
  • Use good open source libraries or tools to improve development efficiency
  • Early can be adjusted single test this stage, such as late really need to write single test

3. Quick bug fixes

Each the use of open source libraries in the early stage should be more or less will have bugs, especially when people try to use your library, released after the encounter bug will give you a big issues, as the author of the open source libraries, at this time should be to the fastest speed to solve the issues, after all, the somebody else is your project early a few users, Not to mention finding bugs for you, if you don’t have good service for that one user, let alone thousands of developers using your library later

So if you do open source, you want to start a business again. The initial group of users who use your open source library (which is not fully mature) are your resources during the cold launch. Only by serving them well can you have a chance to have a successful cold launch and become widely known

One reason for Babel’s success is that it fixes bugs quickly and releases new versions. Bugs are usually fixed and released within minutes of being reported. This was crucial when there weren’t many early adopters. Users will feel that the maintainer of the library is very efficient, and even if they encounter bugs, they will not complain that the library is buggy and give up using it

4. Promotion

Promotion into a word called “headache” marketing, may be you will think of marketing, but it is not let you go to in order to promote their open source library and do some “dirty”, or even pull on other libraries so as to raise their own library ha, can let a person dislike this malicious marketing, timely your library again good, is it here

Harm, really headache, worked hard to write a library, but also to promote, do not promote no one to use, no one even know!

So what do we do?

Share it with friends and colleagues and ask them for advice. If you’re lucky enough to have users who try out your library early on, they can give you advice and even help spread the word!

If you have the opportunity to share your project with a wider audience, you can introduce and communicate with them in interesting ways. For example, make a few interesting promotional videos about your project, tell a short story about yourself and your project, write a technical blog that introduces your project directly or indirectly, etc

Fred spent a lot of time writing a blog post about why Snowpack was born and everything he was working on with the project. It went viral and was shared and quoted by many users in the following year, but it grew very quickly!! I think it should be Fred’s article to write more heart, can let everyone feel ~

In fact, there is an open source library author in China who has done a better job in promotion. He is xu Xiaoxi, the author of H5-Dooring. In recent years, he has been promoting his open source library on LowCode by writing technical articles in many communities. Knowing that there is such an excellent open source library. On the other hand, people should trust him more, after all, he can output technical articles to show to everyone, exchange and discuss ~ this is also a virtuous circle

5. Listen to your users

Now that you support free speech, you’re sure to get a lot of comments when you’re promoting your open source library. For example:

  • You this function, XXX library is not already realized? Is it fun to repeat the wheel?
  • To give the author a suggestion, I feel that the realization of XXX function can be changed into XXX scheme, which is better
  • This library is so buggy, it would be better to use XXXX
  • What a great feature! I hope to maintain it forever
  • .

You see, the reviews are both good and bad. You also have the ability to distinguish between different kinds of feedback, not to let the amount of praise go to your head and be satisfied with the moment, and not to let some criticism get you down. Praise should encourage you to make your open source libraries better, and accept well-meaning advice with humility. When criticized, the first thing you need to think about is whether you didn’t publicize your open source library well enough to cause users to misunderstand your library. Should you rewrite your readme.md or introduce it to the community again? Next, consider whether your critic is just sitting around and stepping on your project in an absolute tone. Try to ignore it and spend more time finding constructive comments!

After all, they are the ones who are actually implementing your open source library!

Make open source mistakes

Of course, Snowpack doesn’t do well, or Fred wouldn’t have run out of energy to maintain it. So what did Fred conclude from his review of maintaining such a large open source project?

1. Use the Dogfooding method

Dogfooding: According to Wikipedia, Dogfooding refers to the practice of using one’s own product or service to support internal testing. It can control the quality of the product in advance and launch it with full confidence

For example, Facebook (FB for short) has opened source React, and many of its internal applications are also developed based on React. If React adds a feature or fixes a bug, FB can also apply the modified React to its internal applications in addition to single test. Verifying the stability of React functionality in a real online project is more comprehensive than just testing it in a development environment. After the modified React has been applied in their own projects for a period of time with basically no problems, FB can be confident that the quality of React is very high and open to other developers.

Fred did not use his own open source library for his own projects as well as FB, so he was not able to ensure the quality of the new Snowpack features before they were released. Instead, before developing the new Snowpack features, Talk to your users.

In retrospect, Fred should have taken the Dogfooding approach and traded his open source libraries for more online functional testing and quality assurance before full disclosure.

2. Ensure quality and quantity, understand users

As Mentioned in Fred’s successful experience, he tried his best to serve the first group of Snowpack users in the early stage of the project. At that time, a certain function was recognized by the initial users, but as more and more people used it, most of them thought this function was bad and even should be abandoned. There is a shift in user needs, so you need to understand user feedback in any link that you maintain throughout the project so that you can move the project forward

At the very beginning of an open source library, there may be a lot of big and small bugs, which is understandable. After all, it is just a beginning, and not many people use it, so it will not cause hundreds of bug feedback or user ridicule. As the project gets on the right track and becomes more and more mature, more and more people will use it. What users expect most is that the library has fewer bugs and more stable functions. Therefore, as an open source, what we should do is to improve the quality of the open source library and ensure the most basic user experience!

3. Collect feedback and actively address it

Not everyone is going to give you feedback. Shoes think about it, if you met problems when using some open source libraries, at this time you will go to baidu search problem solution, search and you will not go to see the library’s official documents or lot issues have similar answers, no words, you probably don’t want to use the library, the in the mind is likely to silently say: The library is so LJ, so many questions, that if you have a little patience, you will issue an issue, longing for the author’s reply, longing for the question to be answered, but if you don’t get a response, you will end up looking for another mature open source library that can equal or surpass it.

According to Fred, the Svelte team had mentioned in a blog post that they were interested in Snowpack, which meant it could be used by the team (user +1). Fred was happy, but later found out that before the official release of SvelteKit, They had already replaced Snowpack with Vite, which did the same thing, and it turned out that the Svelte team wasn’t very happy with Snowpack, and as I mentioned before, they didn’t give Fred any feedback. Because they may have no time and patience to go through the complete link of “feedback -> waiting for solution -> problem solved” for various reasons, at this time there happens to be another library to meet their needs, and basically there is no problem, isn’t that beautiful?

Fred later reflected that he thought Snowpack did a good job of communicating and interacting with users in the early stage, but as the user base became larger and larger, it did not have a strong sense of interaction with users, and some users naturally flowed away. Fred later learned that the Svelte team often had problems using Snowpack, but Fred received their feedback too late because they had given up using Snowpack.

In this regard, Fred himself summed up a lesson: as the creator of open source libraries, it is important to keep good feedback channels and strong interaction with users. Don’t just wait for users to give you feedback, be proactive in gathering feedback and solving problems quickly

4. Continuous output and continuous improvement

An open source library is always created to solve a problem, but the problem is endless, and the function of the first version is usually relatively simple, so the open source library has to be maintained all the time. For open source itself is not a easy thing, because once the user group, the numerous issues will be sent to you every day, there are a lot of problems and bugs, waiting for you to solve, but the community is friendly and very active, often have students willing to find problems and feedback, even ability good students will also make a contribution to the pr some code, This is open source at its best

As the creator of open source project, what he should do is to take the initiative to solve the problems of user feedback, carefully review the code submitted by others, and at the same time think about what can be improved in his own project. In short, he should continue to improve the open source project. Your audience will also see that you are a good, responsible person in terms of your productivity (wow! This author submitted code a dozen times a day! I fixed the bug 2 hours ago so quickly! How efficient! The trust generated in you can also be reflected in the open source projects you do

It seems that open source is time-consuming to hear here! Are you going to quit your job and do open source full time? Not really! The number of people who can make a living doing open source full-time is very small, and most of them are part-time or even part-time. It’s ok to do open source on the side, but it’s better to spend a few hours a week or a few days a month maintaining your open source projects than it is to leave them alone

In fact, the community can also feel your commitment to open source projects (this library was last submitted half a year ago, and accumulated more than 500 issues unresolved! I don’t know if it works!) If you don’t try to maintain it continuously, then the community tends to calm down, which is the biggest problem with open source, and Fred says he’s seen this happen in many large open source projects. You can’t rely on your community friends to give you pr to maintain open source projects, can you?

5. Build community

This point should be needless to say, everyone can feel. To their open source project to build a communication community just like merchants create VX group of customers, it will “merchants” and “user” of communication link shortened, but also can provide with a functional purpose user discussion platform, they can actively give ideas, can also be helping each other, you can also gain valuable feedback from the community

6. Many hands make light work

This last point was probably one of the biggest reasons Fred didn’t have the energy to maintain Snowpack

There are plenty of Snowpack molecules, including 402 at the time of this writing. We can see that the community is very active and willing to help maintain this project. Judging by this trend, Snowpack will go better and better, right?

But Fred didn’t think so! He always wanted to maintain Snowpack all by himself, and did not accept Larger Contributions, because his short-term thinking told him that he would be more efficient in doing it by himself (after all, there was no need for multiple people to cooperate, thus avoiding many cooperative problems). Indeed! During that time, Fred exported a lot of stuff, and it was very efficient indeed! But in the long run, the problem will only gradually emerge. Fred’s output of a lot of content is based on the premise that he is in a hurry to complete the function and skip the code review. If he is confused, he will always return it. If he keeps doing this, sooner or later, the maintenance cost will be higher due to the poor quality of the code and the disorder of the structure

I rushed to take a look at Snowpack’s Larger Contributions. There were not many of them, including two of Fred’s own!

To sum up, after the open source project grows, it is not only to rely on a single fight. It is wise to find interested and capable partners to form a team and build it together. After all, open source is not only about writing code, there are many things to do, such as: New features and bug fixes, collect and solve the problem of users, promotion, and write the official document, etc., finally combined with warm-hearted friend’s help, team and community will be able to smoothly promote the progress of the open source project, if the subsequent open source project profit, as a creator you can also regularly give friend within the team some Money, after all, who are not power for love ~

gossip

SvelteKit has given up Snowpack in favor of Vite. Does anyone think Vite killed Snowpack? Fred also looks back at Snowpack’s life and sees a lot of problems with open source. He can only say that no one else has the experience to do open source

To get more specific about Vite, you can see from the official Vite documentation that Vite borrowed Snowpack V1’s dependency pre-build feature, so the two libraries are very similar in that respect, and many of the community’s bigs often write about them. Why was Vite born? It is said that when using Snowpack V1, Utah found that the library did not support HMR very well, so they created Vite and provided HMR based on native ESM. Similarly, Snowpack V2 later implemented this feature from Vite

Fred was generous enough to say that Vite was doing a great job and that he would be moving his own project Astro from Snowpack to Vite in the future

Vite, meanwhile, is growing by leaps and bounds. To their credit, they do a lot of things very well. The good news is that the two tools are very similar and easy to switch between. Even then Astro will try to migrate from Snowpack to Vite.

Indeed! Standing in the perspective of Vite to review all the chapters mentioned in this article, Vite did really good, development efficiency, problems and bug repair speed, promotion, improve the document (both In Chinese and English), continuous output, quality and quantity, expand the ecology and so on, no wonder will be praised by Fred ~ give you a praise!

conclusion

Read Fred’s open source summary (he is very modest), benefited a lot, but also hope to do open source in the future or now you a little inspiration ~

I mixed in a lot of my personal thoughts, incorporating Fred’s summary bit by bit into this article. If you want to see the original text, I put the link here

  • Dev. To/fredkschott…

If you have any questions, please point out 👏🏻! If you have any ideas, please leave them in the comments section.

I am one, share technology, more than the front end!