Live data from Hacker News

What Have We Learned from This Open Source Project?

taskwarrior.org

51–54 of 54 posts

Re: What Have We Learned from This Open Source Project?

#51
post #22

Earlier quoted context omitted.

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…

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…

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.

Re: What Have We Learned from This Open Source Project?

#52

"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.

I like this quote: "If you like writing code but you don't like dealing with bug reports -- and you should be so lucky that your code is popular enough that you actually get any -- then you're no hacker, you're just someone who gets a good score at Sudoku."

- https://www.jwz.org/blog/2013/02/wow-remember-when-people-tr...

Re: What Have We Learned from This Open Source Project?

#53
post #50
post #26

Earlier quoted context omitted.

If I used your software, I would totally fork your project and have a less totalitarian view of the project's leadership. You're free to think you "own" your community, but as Oracle and many other examples have told us, that's not the case and the community will make sure you learn your lesson.

I'm not advocating for anything other than community ownership of projects, only a few formalities. Thinking that everything has to be absolute anarchy in order to be "free" (even that open source's goal has to be to maximise "freedom" over any other kinds of social utility) is a kind of absolutism/idealism that I wish open source communities could leave in high-school where it belongs.

The two choices are not "anarchy" and "everything except the code we output should be private".

Re: What Have We Learned from This Open Source Project?

#54
post #51

Earlier quoted context omitted.

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…

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…

> 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.

Post reply on HN