Bower: building a community is hard
If you use JavaScript, you might have heard of Bower. If not: it’s a package manager for the web. A lot of people seem to love it, but recently the rumors of Bowers death started to circulate on Twitter.
The reason for these rumours is this GitHub Issue. A contributor wants to add some important feature. Turned out there is only one person working on Bower and this person doesn’t have the time to review the patch.
Almost instantly somebody started crying “Bower is dead”.
But guys, it’s open source. Complaining and panic is the wrong reaction. Because the original author of Bower made the source code public, it is possible to help. Sit down in your free time and code.
Is it dead?
However, Bower is indeed in a bad situation.
The Bower organization counts 25 members.
One could be excited about so many persons, but, unfortunately, the contributions to the Bower core doesn’t look that bright.
Two persons contributed most of the code. All the other 156 contributors listed only contributed little code. Looks as most of them just created a few lines here and there. There is no long-term commitment to the project.
As much as I like GitHub as a tool, it was always clear to me GitHub is not made to build community around open source projects. And this is what happened here: a lot of people fork and some send a “pull request”. Only a few people stick and feel responsible.
Community over Code
At the Apache Software Foundation projects usually have a community (at least the active ones). The saying is “community over code”. How do we maintain the community?
- With Mailing lists: it may feel a bit dated, but it’s a powerful, inclusive tool to let people participate.
- The ASF conference is another great way to meet all the other people. A get-together is maybe the strongest weapon to build communities.
I can’t remember how I was sucked up into the ASF, it “just happened.” And I found friends there. Despite I have very little time these days, it is unlikely that I leave the organization soon. I can even manage to write at least the most pressing emails.
I am not saying the ASF is the best place for each any project, and I am surely not saying the ASF is the right tool for building communities. If you try to join the ASF without a good community already, it will be hard to grow one there. I would say new projects with only five active people will have a hard time to graduate from the Incubator (the place, where all projects start until legal and other things are clarified). Maybe it is better to say the ASF provides an environment to nurture an existing community, which maybe will grow.
Money is not the hammer for any problem
Valuable and reliable Open Source projects need a community. If there is none, you - yes YOU - are asked to create one. That’s how Open Source works: everybody gives a little of his time, and in the end there is something great going on.
Bower thinks money will solve the problem. If you are too busy with earning money, the only solution seems to offer more money. Now there is a form you can fill to declare how you want to help, and the amount of money you would expect for your help: https://github.com/bower/bower/commit/3ab71f27fff4e5554ca6d9295a85fae47705fc40
From my observations, projects are usually surviving well when a few people have paying companies in back. In an example, Adobe accepts their developers spend time on Open Source projects. Good examples are Apache Cordova, but also Apache Commons. They pay them for developing their products, but if they need something which is Open Source, they fix it. Committers usually stick with the projects they need for their daily work. Please note: not all committers can work on the projects in their work time. I know only a handful person that can. Personally, I was never working for the ASF at work time until I became self-employed.
It’s a very modern approach for a company. What, if all companies which use Bower would allow their developers to participate in the project, they are using daily? It would work. Honestly, not Bower is broken, nor the people complaining it is dead. We only have that situation because companies want to use the tools, without donating time from their developers to develop them!
Not many companies understand how Open Source works. The Bower team looked for different solutions and thought about funding. It was asked for $5000 to implement and support the new feature of lock files. But what then? It is not the only feature people need. $5000 might (!) guarantee a feature, but not that Bower is still a thing in 2 years.
Out of the misery
Bower has a serious problem. There are only two ways of getting out of this misery that I can imagine:
- find passionate people who have fun working on Bower. Make them core committers, but also create a community with them.
- one (or better more) companies hires a person to work on Bower, or at least allow the person to take care on the project at work time.
Option 1 will be hard. There are always people who say they want to help, but when the buzz is over, they disappear. Making them stick requires more than just putting a smiley in a pull request. The project needs to utilize more tools than just GitHub.
Option 2 would be good, but it would ultimately end in a fork. When the core team does not have time/passion for reviewing changes, how should they decide to give write access to a new committer? Only when the Bower team is open to adding new people and “trust” them right from the beginning, the original Bower repository will stay.
But on the other hand… isn’t forking what GitHub made popular?
Sharing patches is easy. Sticking with the project, keeping it alive and making it vibrant is hard.
Image Credits
- Mlini, Croatia: Ivan Ivankovic. CC-0.