Hacker News Reader

Comment by cloverich | Hacker News Reader

> Yes it can hurt if your contribution is coldly cast aside, and yes it would be much better if they warmly took you in and taught you in their ways, but if the OSS project leaders don't keep up the constant stream of contributions, improving the project all the time the project will die and all work will have been in vain.

Perhaps I'm being naive, but doesn't fostering relationships with contributors promote more contributions? Or is it considered far too rare that a (somewhat) mentored contributor will continue to contribute?

View on HN

It's an investment. The first few patches from a new person will likely require so much hand-holding from the maintainers that it would have taken them less time to just write the patches themselves.

As that new contributor learns the ropes, though, that cost goes does. Eventually they hit break-even where they are adding more value to the project than they cost. But that requires the person to stick around long enough to get there. There's a pretty high chance any new contributor will lose interest and go do something else.

So whenever a maintainer gets a new patch from a new person, it's always an open question as to whether taking it in will ultimately be a win for the project. Unless you can predict the future, you can't tell if that investment will get amortize out and yield something useful.

I have 1 patch in the git kernel. I barely knew c when I did it but I did tons of research on what to call and how. Junio (maintainer) took my barely workable patch and told me what to fix. Let me do it, then pulled it in. Amazing experience in a very scary environment, eg non-minimal chance Linus tears into you.

Agreed that fostering relationships with contributors promotes more contributions.

But, if someone's first contribution had naive mistakes, and it took more of your time than it saved, I can sympathize with a leader who doesn't try to get similar contributions.

More contributors means more work for the project maintainers since it's more code they have to review, discuss, and commit. Very often the maintainers don't care about bug fixes or enhancements if it's not for something that's impacting their work.

How can bug fixes and enhancements not impact their work?

Any number of reasons. It could be a platform specific issue, a feature they don't use, something they don't consider a real problem.

That's certainly Gina Trapani's philosophy with ThinkUp, and it seems fairly successful.

http://smarterware.org/7819/my-codeconf-talk-your-community-...

Reply on news.ycombinator.com