Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

An Open Source Author's Lament

github.com

Post reply on HN
Print view View original

51–57 of 57 posts

Re: An Open Source Author's Lament

#51

Post by rbanffy »

Osmose wrote: post #45
rbanffy wrote: post #36

Is it really that hard to get people don't write open source to solve your problems? What state of mind makes people believe they are entitled to someone else's time? When I write software, I'm solving my problems. When I write open-source software, I'm still solving my problems, but I find whatever I'm writing may be useful to someone else, so, feel free to use it and, perhaps, even join the effort to continue bette…

As someone who writes open source software to help solve other peoples' problems, all I can tell you is that it makes me happy to help other people. There's no logical reasoning behind it beyond that I feel good when I've helped someone else accomplish their goals. Sure, you could analyze the cost and benefits of it, and maybe even find a logical reason as to why it makes me happy, but _I_ didn't. I just enjoy it! :D

That's the point - you do what you want because you enjoy it. I program because I like programming and I enjoy solving the problems people I like have. Solving a lack of enjoyment is solving a problem.

But I don't enjoy programming for people I don't like.

Re: An Open Source Author's Lament

#52

Post by Serow225 »

JonnieCache wrote: post #33

Perhaps contributing.md should be embedded above the new issue form in the same way that readme.md is embedded on the project homepage.

Send your idea to support@github.com; I did that for a suggestion I had regarding the github UI, and got a nice response back in a day or two. They also confirmed that this is their desired way to collect feedback/suggestions.

Re: An Open Source Author's Lament

#53

Post by adekok »

rbanffy wrote: post #36

Is it really that hard to get people don't write open source to solve your problems? What state of mind makes people believe they are entitled to someone else's time? When I write software, I'm solving my problems. When I write open-source software, I'm still solving my problems, but I find whatever I'm writing may be useful to someone else, so, feel free to use it and, perhaps, even join the effort to continue bette…

> Is it really that hard to get people don't write open source to solve your problems?

Yes. There is a persistent set of well-intentioned but clueless people.

> What state of mind makes people believe they are entitled to someone else's time?

"I want the software to work. You wrote it, you need to fix it! It's your problem. What's wrong with you? Why won't your software work? I need it for a deadline! Please fix it now!"

I've been running an open source project for ~15 years, with many millions of running installations. The only solution I've found is to ignore these people. The "d" key comes in handy. Where that isn't possible, I ban/block them.

The level of cluelessness can be seen in the following typical exchange:

- user engages in anti-social activity

- I say "stop or you will be banned"

- user repeats the anti-social activity, and calls me names for "threatening" him.

These people don't even realize that annoying the mailing list administrator is unproductive. It's like their psychology is missing a reward/punishment feedback loop which normal people have.

Re: An Open Source Author's Lament

#54

Post by adekok »

jaggederest wrote: post #31
doppel wrote: post #20

Earlier quoted context omitted.

While these are excellent suggestions, if you check out the links he makes to other posts there is a LOT of noise in there that he has to wade through, weigh (open/close/discuss) and take action on. My interpretation of it is that he is lamenting how the issues list has become a catch-all for everything from bug fixes (which are fine) to random non-Backbone related development questions, and looking at the issues at…

Honestly, this all comes back to the issue "Why is the person who does the majority of the programming also doing the majority of the customer support?" Let someone else close issues that are offtopic or a bad idea. He insists that this means that 'you have more people who have to read everything' but it absolutely does not. It means you need to learn to trust that if so-and-so closed it, it should be closed.

> "Why is the person who does the majority of the programming also doing the majority of the customer support?"

Because no one else cares. It's a huge problem in Open Source projects. Most of them are single-person projects. One person does the coding, bug fixes, releases, documentation, and answering questions on the list.

For the OP on github, he needs to learn triage. There is no reason to be polite to people who can't be bothered to read the documentation. My mantra is "if you don't care enough to put some effort into it, then I don't care, either. Go fix it yourself."

He needs to quickly read issues, and close the idiotic ones with minimal comment. If they keep arguing, block them.

A good project maintainer can't afford to waste his time on loud-mouthed idiots. There are too many quietly competent people who need his time.

Re: An Open Source Author's Lament

#55

Post by Afforess »

hayksaakian wrote: post #23

Issues need a priority/voting system a lá reddit. People who run the project could set a minimum for getting notifications about issues. Different maintainers could have different minimums.

Because reddit voting is an excellent example of user moderation. /sarcasm

Re: An Open Source Author's Lament

#56

Post by dmiladinov »

lifeisstillgood wrote: post #14

We seem to be forgetting the explicit reasons git was created - to remove the technical commit restrictions and make it a social committing ability - that is the social leader of the project only needs accept commits from people he filters And we are forgetting the long lessons of bug tracking in the wild - don't overload the use cases 1. Can github explicitly limit the people able to make a issue to those who have t…

I'd like to piggy-back on your mention of Linus. It reminds me of a recent video I saw wherein he talked about how the work on the kernel works within a natural hierarchy.

The whole video, IMHO is worth a watch, but the relevant snippet is here, you can watch from about 15:57 to about 18:20 to get the idea:

https://www.youtube.com/watch?v=MShbP3OpASA#t=15m57s

I especially liked his comment at the end of this section:

"The way people work ... is inherent in our brains ... the whole development process ... works really well ... we used the hierarchy that just worked on its own, and that turns out to be the right hierarchy."

Re: An Open Source Author's Lament

#57

Post by lifeisstillgood »

dmiladinov wrote: post #56
lifeisstillgood wrote: post #14

We seem to be forgetting the explicit reasons git was created - to remove the technical commit restrictions and make it a social committing ability - that is the social leader of the project only needs accept commits from people he filters And we are forgetting the long lessons of bug tracking in the wild - don't overload the use cases 1. Can github explicitly limit the people able to make a issue to those who have t…

I'd like to piggy-back on your mention of Linus. It reminds me of a recent video I saw wherein he talked about how the work on the kernel works within a natural hierarchy. The whole video, IMHO is worth a watch, but the relevant snippet is here, you can watch from about 15:57 to about 18:20 to get the idea: https://www.youtube.com/watch?v=MShbP3OpASA#t=15m57s I especially liked his comment at the end of this section:…

Thank you - had not seen that.

no swearing either :-)

Post reply on HN