
What Have We Learned from This Open Source Project? - oddell
http://taskwarrior.org/docs/advice.html
======
RKoutnik
"Do not start an open source project if you need praise, warmth and love from
your fellow human beings."

Ugh, very true. Folks forget that most FOSS work is volunteer & berating the
hackers who make it won't help one bit. Worst is the issue reports about a
fixed bug, followed by "What version do you have?" aaaaand silence. At the
very least come back and close the issue.

~~~
lotyrin
Yeah. Open source seldom realizes it needs the same infrastructure as a
commercial product: separate project management issue queue and support issue
queue.

What are we doing next, what version did we fix Y in, what VCS branch are we
working on Z in, who is working on X, etc. are separate from Who reported
problem, what version of the product do they report having used, what did they
expect and what did they get, is that part of the design of the product, did
they ever get back to us, etc.

The other problem is ill-defined roles. If everyone's a developer is a support
volunteer, is a user, then you can have people be pretty shitty and reflect on
the project in a way that they shouldn't be allowed to.

Random users should be able to file support tickets, but only to view project
management tickets.

Only designated volunteers should be able to respond to existing support
tickets and create project management tickets from them, these people speak as
the public face of your project, that's really really important to have a
handle on.

Support tickets probably shouldn't be public, for that matter.

Now of course this is all unpaid, volunteer -- I'm not saying any of these
queues should have a defined SLA or anything. By all means keep project a
bazaar -- let support queue handle outside feature requests and feedback and
everything -- continue to have a public repos, roadmap and changelog, etc.

~~~
jrochkind1
I know what you mean, but there's another side. For instance just on:

> Support tickets probably shouldn't be public, for that matter.

Open GitHub issues, combined with Google, have turned out surprisingly useful
to me as a user of open source packages. Often an answer to some trouble I've
run into is found in an issue -- both 'support' ticket style issues, and
development roadmap style issues, and the line sometimes gets blurred.

Also, there's a positive aspect of the blurring of the boundaries in open
source -- when a user contributes code, or documentation.

But yeah, people running open source projects need to at least think about how
they're going to deal with project management as well as support at some
point, and just the thinking about it and the iterating to figure out how to
do it better is for some a chore they don't want to do. The projects that
figure out how to do this well are the ones that are a joy to use or to
contribute to though.

Oh, and my experience I'm talking from is with open source code packages meant
for use by developers. Open source end-user applications (including OSs like
Linux) are a different animal, and are _much harder_ to deal with support and
project management and the overlap, in my observation. Not sure which you were
thinking of, but now I'm thinking maybe end-user apps.

~~~
lotyrin
Agreed, but I think stack-exchange style communities are better at this than a
project's issue queue or a support channel.

There's also nothing preventing common support issues getting turned into
documentation improvements, creating googleable (but more concise) results.
I'd rather find a wiki page for "libchitz Error: Insufficient Flurbos in
/var/lib/blips" than a forum post/issue with tens of comments and have to
scrape through the results.

Also, there's plenty of times googling something should get you a
documentation page on a subject but instead gets you forums/issues/etc. that
aren't helpful.

~~~
jrochkind1
> There's also nothing preventing common support issues getting turned into
> documentation improvements,

Nothing but someone with the time, willingness, and skill to do it well. Which
is not nothing. A lot of the amazingness of GitHub's effect on our work is how
it gives us lots of useful stuff that happens as 'byproducts', without someone
needing to spend time and energy to do it well.

------
VLM
There is some internal contradiction and repetition.

One repeated theme is what people won't talk about, do talk about, and loudly
social signal about, generally have nothing in common, so assuming any of
those individually is a universal truth is likely to be a disaster. This
applies to a lot more of life than just FOSS development.

As an example of contradiction was the claim that people won't read the docs
but they will watch animations. The reality as seen above is 99% of the
population will read the docs and never contact you unless your docs suck,
0.9% will watch the pictures, and 0.1% will aggressively track you down and
ask you to read the docs for them. Although adding animations will cut
annoyance contact by 90%, that doesn't mean gifs are the only thing that
matters; the docs are what's really important.

------
brbsix
I've noticed some cultures tend to have unusually high standards for open
source software and an expectation of personalized support. Perhaps because of
the pervasiveness of "freemium" business models, I think a lot of people are
really oblivious to the realities of open source. E.g. That they are not
customers, nor are they owed anything in particular.

------
r-w
Hasn’t the original author of “What Have You Tried?” themselves discouraged
blind application of that prompt?
[http://mattgemmell.com/hindsight](http://mattgemmell.com/hindsight)

------
Gisleburt
This was a great read and made me less fearful of my own impending Open Source
attempt.

------
scr4ve
So many true points in there. Thanks for the read!

------
SomeGermanGuy
These are very good points here.

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

The irony of people getting annoyed because of "missing restrictions".

~~~
anc84
It's about missing guarantee of future freedom rather but I am sure you know
that.

~~~
legulere
Copyright owners can always decide to release future versions under whatever
license they please.

~~~
quadrangle
A project that's copyleft _and_ accepts contributions under copyleft without a
CLI means that nobody has the power to unilaterally bypass the copyleft term
for the whole project.

