I maintain a lot of open source projects. In order to do so, I have to effectively manage my time. Most of my projects follow this philosophy: if you want something changed, send a patch. If you are running into an annoying bug, fix it and send a patch. If you want a new feature, implement it and send a patch. It’s definitely a good idea to talk about it beforehand on the issue tracker or IRC, but don’t make the mistake of thinking this processes ends with someone else doing it for you.
Every developer who contributes to a project I maintain is self-directed. They work on what they’d like. They scratch their own itches. Sometimes what they’d like to work on is non-specific, and in that case I’ll help them find something to do based on what users are asking for lately or based on my own goals for the project. I often maintain a list of “low hanging fruit” issues on Github, and I am generally willing to offer some suggestions if someone asks for such a task. However, for more complex, non-“low hanging fruit” tasks, they generally only get worked on when someone with the know-how wants it done and does it.
So what does this mean for you, user whose problem no developer is interested in? Well, it’s time for you to step up and work on it yourself. I don’t really care if your problem is “a showstopper” or “the only thing preventing you from switching to my software”, or any of a number of other excuses you may have lined up for getting someone else to do it for you. None of the other regular contributors really care about your interpretation of what their priorities should be, either. We aren’t a business. We aren’t making a sale. We’re just making cool software that works for us and publishing it in the hopes that you’ll find it useful, too.
Generally by this point in the conversation with Joe User, they tell me they can’t do it. Well, Joe User, I beg to differ. It doesn’t matter that you don’t know [insert programming language], or haven’t used [insert relevant library] before. You don’t learn new things by hanging out in your comfort zone. Many of the regulars you’re bugging to do your work for you were once in your shoes.
Everything is setting you up for success. You literally have hundreds of resources at your disposal. The internet is was made by developers, you know, and we built tons of resources to support ourselves with it. You have documentation, Q&A sites, chat rooms, and more waiting to help you when you get stuck. We’re here to answer your questions with the codebase, too. I pride myself on making the code accessible and easy to get into, and I’ll help you learn to do the same when you integrate your with our project.
We would much rather give you advice on how to fix the problem yourself than to fix the problem for you. Even if it takes more of our attention to do so, we get the added benefit of a new person who is qualified to help out the next guy. A person who is now fixing their own bugs and improving the software for everyone. That’s a much better outcome than having to waste our own time on a task we aren’t interested in.
It might be hard, but hey, it’d be hard for us too. You’ll learn and be better for it. Wouldn’t it be nice to add [language you don’t know] or [library you don’t know] to your resume, anyway? If you’re concerned about the scope of your problem, how about asking about the low hanging fruit so you have easier tasks to learn with?
The cards are stacked in your favor. The only problem is your defeatist attitude. Just do it!