Living with 1000 Open Source Projects

Open Source Developers

Nic thinks there are two types of open source developers and contributors.

1. Type A are enthusiastic developers. They announce their projects, help their users both use the project and occasionally even learn the language. They write blog posts and ask others to write blog posts. They share those blog posts and so on.
2. Second, there are those that used to be of type A.

Some people give up silently, avoiding their projects and maybe the Internet as a whole. A few do it publicly. Jamis Buck, for example, quit Capistrano and its related networking libraries back in 2009 in his "Net::SSH, Capistrano, and Saying Goodbye" post. Ironically, I've been silently ignoring maintaining a Capistrano plugin of mine for about 7 years now.

While Nic says he doesn't have projects as popular as Jamis', he has ended up with numerable smaller repositories over the past years. He also thinks there are probably more people with crappy projects than with popular projects like Capistrano that need talking to.

Justifiably, with only 168h per week, he finds it impossible to tend to each of his projects. It's necessary to reduce the amount of time spent on any project. He illustrates this with an analogy of pets.

Like children or pets, pet projects don't scale well. A few are fun, but more than a handful can't work. First, Nic suggests you pick a few to be ones you'll care deeply about. For those you may end being known for. Second, projects you perhaps needed for work and happened to publish as an open source library, should be designated as work. That is, their maintenance is something you'll also be doing during work-hours. That "scales as much as work does". The rest you should just ditch.

Reducing Your Maintenance Burden

The next goal is driving down the maintenance effort. As a result, you may occasionally see people complaining about your project's status online. Nic finds it unfair. Just because you open sourced it doesn't imply you've bear the obligation for maintaining it. He does, however, have a few ideas how to minimize the impact of reduced attention and manage expectations.

You could publish the project status on its page. The number of days since the last commit could be a good indicator. For handling questions and assistance requests, you could set up a mailing list or forum where people could come help each other. These days GitHub Issues would probably suffice, if you're hosting your code there.

In addition to solving communication, helping people find each other's patches could reduce your workload. GitHub's project fork view will in come in handy. People could then pick a more up to date fork or collect patches themselves.

Instead of still considering the abandoned projects as your projects, Nic suggests viewing them as ones you're merely looking over. This could permit you to share commit rights more freely.

I'm not sure I personally agree with that liberal view of commit access. Your original dependents may have chosen your project not only for its merit, but for your reputation. Giving maintenance permission to a seemingly helpful yet random contributor would betray that trust and possibly cause a security nightmare for your users. Unfortunately, we're not talking about a hypotheticals either. A recent and popular case showed up in late 2018 where someone taking over the event-stream Node.js module from its original maintainer ended up back-dooring it. This was well described in Snyk's post-mortem of event-stream.

Driving Down Maintenance Cost

Nic mentions libraries of Rake tasks (like Hoe) to package and deploy projects. Having a Rakefile at hand means less thinking of the process, further saving you time and reducing the need to help others manually.

Reviewing bug reports could take up to half an hour to reproduce the bug. To avoid having to deal with bug reports in the first place, Nic suggests taking quality control more seriously and writing tests. He's using MultiRuby from ZenTest to run tests against different Ruby versions.

Links

• Nic Williams' GitHub profile