1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
|
---
# vim: tw=80
title: Actually, you CAN do it
layout: post
tags: [philosophy]
---
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!
|
