What Have We Learned From This Open Source Project?

Here is the collected wisdom that we have gained from running the
Taskwarrior project for nine years. It has been rewarding,
enjoyable, and sometimes frustrating. We learned a lot about
users and Open Source expectations.

Advice To Open Source Project Contributors

Start an open source project if you want to learn all you can about
software design, development, planning, testing, documenting, and
delivery; enjoy technical challenges, administrative challenges,
compromise, and will be satisfied hoping that someone out there is
benefitting from your work.

Do not start an open source project if you need praise, warmth and
love from your fellow human beings.

If you could draw a boundary between that which is already
supported, and that which is not, you would find that all
the activity, discussion and drama occurs at that boundary.

Feature requests only nibble at the periphery.
Bold changes originate elsewhere.

People will get excited about something a project doesn’t yet
support. Deliver it, and they will get excited about the next
thing.

If a feature works well, you’ll never hear about it again.

There is a fine line between “richly-featured” and “bloated”.
There may not be a line at all.

If you demo two features, and talk about twenty more, users still
only know about the two. Visual demonstrations have far greater impact.

Every change will ruin someone’s day. They will be sure to tell
you about it.

The same change will improve someone’s day. You will not hear of this.

People will disguise feature requests as bugs, which means either
they consider difference of opinion a defect, or believe that
calling it a flaw will force implementation, but hopefully they
just forgot to set the issue type to ‘enhancement’.

Some people find it very difficult to articulate what they want.
It’s worth being patient and finding out what they need.

What you keep out of a project is just as important as what you
allow in to a project.

Many new users will submit feature requests, just to show that they
are knowledgeable and clever. They don’t really want that feature,
it’s a form of positive feedback.

Beware of suggestions from users who have used your software for
only a day or so. Be equally aware of suggestions from users who
have used your software for a long, long time.

People will threaten to not use open source software because it lacks
a feature, thereby mistaking themselves for paying customers.

Many believe that if a change is small, it deserves to be in the
project, regardless of whether it makes sense for it to be there.

Users will go to the effort of seeking you out online, to directly
ask you a question that is answered two clicks from the front page
of a website.

A looping, animated GIF will be watched over and over, scrutinized
and understood. A paragraph of text will be ignored.

Man pages are too densely crammed with information, and too lengthy,
for most modern humans to ingest.

“What have you tried so far?” is the best question to identify
time wasters.

People will pick a fight with you about all your incidental choices.
Your issue tracker, your branching strategy, your version numbers,
the text editor you use, and so on.

You can choose the most permissive software license, and people will
still argue with you about your choice.

SEO consultants are not very good at searching the web, and learning
that you operate an open source, non-profit project. It says a lot.