7 ms·

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

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

kuschku 11y ago
Which is why many people now have automated bug reporting tools. Which is sad.
- wingerlang 11y ago
  What's wrong with automated bug reporting tools? I am very grateful for the 100/1000s of automated reports we get, they would be near impossible to shake out of even a technical user.
  - kuschku 11y ago
    Because then the whole free software crowd starts marking your app as "Evil" and containing non-free antifeatures. It’s hard to find a good solution.
- jrochkind1 11y ago
  I'm not sure what you mean, what kind of tools, that are sad?
  - pitay 11y ago
    I think he means reporting built into the program itself, such as when the program crashes. I don't know why it is sad.
  - kuschku 11y ago
    Because now your only solution is sharing as much information as is necessary for understanding the bug with your own server. Which a lot of people in the free software crowd dislike, because of privacy implications. I, personally, dislike it, too.
lotyrin 11y ago
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.
- cyphar 11y ago
  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.
  - lotyrin 11y ago
    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.
    - 11y ago
asjo 11y ago
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-tracked-bugs-welcome-to-the-next-level/#comment-126970 https://www.jwz.org/blog/2013/02/wow-remember-when-people-tr...

kuschku 11y ago

Which is why many people now have automated bug reporting tools. Which is sad.

wingerlang 11y ago
What's wrong with automated bug reporting tools? I am very grateful for the 100/1000s of automated reports we get, they would be near impossible to shake out of even a technical user.
- kuschku 11y ago
  Because then the whole free software crowd starts marking your app as "Evil" and containing non-free antifeatures. It’s hard to find a good solution.
jrochkind1 11y ago
I'm not sure what you mean, what kind of tools, that are sad?
- pitay 11y ago
  I think he means reporting built into the program itself, such as when the program crashes. I don't know why it is sad.
- kuschku 11y ago
  Because now your only solution is sharing as much information as is necessary for understanding the bug with your own server. Which a lot of people in the free software crowd dislike, because of privacy implications. I, personally, dislike it, too.

lotyrin 11y ago

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.

cyphar 11y ago
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.
- lotyrin 11y ago
  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.
  - 11y ago

asjo 11y ago

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-tracked-bugs-welcome-to-the-next-level/#comment-126970 https://www.jwz.org/blog/2013/02/wow-remember-when-people-tr...