Recently I received an email from an IT student asking the following: I recently submitted a pull request to one of your open source projects on GitHub. What can I do to get this pull request merged? The answer below may sound somewhat like a cop-out, or harsh (especially considering it was to a starry-eyed student trying to dip his or her toes into the waters of open source software contribution)... but I've found that honesty is the best policy, and the best way I can maintain good OSS software is to guard my (limited) time for OSS work vigilantly, and try to not allow sentiment force the merge of any kind of code, no matter how simple/small the change. Here is my reply:
Thanks for the email! I maintain over 100 different open source projects on GitHub, all in my spare time (which can be hard to come by with 3 kids, a full time job at Acquia, and a few other hobbies!). I spend a few hours per quarter on any given project. Some of the more popular projects have dozens of issues, PRs, and new comments that need to be read through to figure out what I need to these few hours on.
I usually prioritize by the following:
- Anything that's breaking current usage (e.g. updates that break things, changes to the software, major bugs).
- Bug fixes
- Easy to understand code optimizations or performance enhancements
- New features that would be useful for the majority of users
- Any other work (e.g. less widely-applicable new features, rewrites)
I'm not sure whether I'll be getting to [the project you indicated] within [the timeframe you indicated], but I wouldn't count on it—the key to getting open source contributions accepted is patience—I have a number of open PRs on other projects, some of which have been open years, others months, others shorter time frames. Unfortunately, since most OSS developers are like me (self-funded, work on things in free time only), there's no guarantee the work you do will be merged in any particular time frame (if ever!).
Thanks, Jeff Geerling
Comments
If you have this little time available for your open source project (a few hours per quarter), then you should work on removing yourself as a dependency..
An open source project can quickly become bigger than the original creator, so let it free when that time comes.
Putting a project into maintenance mode because you don't have time and you want to keep all control is a decision you make yourself, it is not out of your control and you should at least own up to it instead of acting as if it is the default and there is no other way.
Also, "starry eyed student" is a very derogatory way to refer to that person.. I think raw passion, positivity and ambition should be lauded instead of looked down upon.. Society could sure use a few more positive people..
To me "starry eyed student" is a compliment.
This comment exactly. I couldn't say it better myself.
I do let it free, by giving the most incredibly free license I can, the MIT license, on practically every project I post—I strongly encourage anyone who wants to fork it, to do so early and often.
But to hand control over a project I started (especially in my namespace or one of my organizations) is actually a lot of work, and something that I would not take lightly. When you do that, you essentially say to all your users: "I trust this new maintainer to treat you as I would treat you, and I am willing to give them control over a project that has my name or organization's identity attached."
That's not something I do lightly, and because of that when I demote a project to maintenance mode, I would rather see a thousand forks spring up than move control to a new maintainer who might betray that trust... or just not do anything at all (besides maybe work on one pet issue), which is what has happened almost every time I've given over a project.