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