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?

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

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

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.

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.

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.

I'm of the opinion that the best thing for large projects is new blood. If large OSS projects rotated people through triage and new contributor on-boarding, e.g. how to make a patch, how to get it approved, and so on, then in the long-run the number of contributors will grow.

But how do you do that without occasionally handing over the maintainership of some important piece of infrastructure to someone who clearly can't handle it? The people at the top of the ladder right now are there because (and sure, there are exceptions) they are (1) very good at it, and (2) willing to do it. And they have employers who have made bets on those two facts. Those employers aren't really interested in someone else taking over when they have someone working now.

I'm sensitive to this, really. I work in an embedded linux world where I end up submitting a bunch of patches to various projects as an "outsider" (often one who is still learning the project in question). And yeah, I get yelled at a lot. And it sucks.

I'd love these people to be nicer too. But honestly I don't see a "process solution" like you propose. We just need to find nicer hard-working ubergeeks. I'm not holding my breath.

There is a very very simple but quite useful technique which should be easily automated: send an e-mail thanking the contributor for the pull request and telling him with courtesy that it may be left to oblivion due to lack of time.

Honestly, for any OSS project leader this should be easy.

All of us know the difference after sending a CV anywhere between:

-1) destroying answer (do not send us your CV anymore)

a) NO answer

b) Automated answer without politeness intent

c) Polite automated answer

d) Personalized, human-written answer

You cannot do d) always but you should certainly do c).

I'm making two assumptions here: firstly that there is a hierarchy of contributors, where triage doesn't have to be handled by the guys right at the top; and secondly that the first few submissions by a new person aren't major--they are going to attempt something small first. If the latter isn't the case, the response should be "sorry, we appreciate your help, but try to get some minor bug fixes in before a major architectural change".

That's actually not the way the real world works though. The primary "jerk" projects (mostly the kernel and Linux infrastructure) are dominated by submissions from paid, professional developers working on support for new features for their employers. These people are routinely coming from closed-source backgrounds, don't understand the project, don't write new feature with an eye to maintainability, and have an affirmative requirement from their managers to get their submissions accepted. As I mention, sadly, I'm in this set more often than not.

That's just not a recipe for fun. The "hair trigger rejection" filters are there because of all the junk that gets thrown at the maintainers. And either it makes them grumpy or is acceptable only to people who don't mind being rude. Either way, the "jerk" bit is a direct correlation.

I think it's unfair to call the OSS project leaders "charity workers" and not the contributors. Either way, if OSS project leaders have so little free time, why wouldn't they spend more of it fostering developers into being more productive members of the project? This is what baffles me most about the situation. It's a lose-lose for everyone when a project leader acts like a jerk.

I think it is unfair to call "contributors" charity workers when all they do is cause headaches for the oss project leaders.

The project leader won't be a jerk to you if you make a nice well-tested, style-adhering commit that only addresses a single issue without breaking other code.

Don't think for a second 'occasional contributors' combined efforts even come close to the contribution of even a single project leader.

The Mythical Man Month. When it comes to software, uniformly accepting and mentoring newcomers into a project does not bring uniformly good return- and in many or most cases, will result in NEGATIVE return, that is, a bad developer can cause progress to move backward, making more work for the other developers- both in working around the badness, and in time spent educating the newbie.

Try Miranda IM ;)