Ask HN: Which open source projects have kind, supportive, talented teams?

247 points by mikemajzoub ↗ HN
Hi HN -

I'm looking to get more involved with open source projects. From your experience, are there any projects that you have been involved with where you are impressed by how kind, supportive, talented, and effective the group of people are that work on the project?

Thanks, Mike

292 comments

[ 4.0 ms ] story [ 252 ms ] thread
The people working on the redox project have been awesome the times I have interacted with them and can always use additional hands. Everyone there seems to buy into the common goal idea. https://github.com/redox-os
Rust is generally awesome.
Agree 100%. The Rust community is excellent.
In my experience the Rust community exhibits a cloaked form of tyranny.

On the surface they are very vocal about supporting 'inclusiveness' and 'non-discrimination' and 'tolerance'.

Yet they use a rather harsh and subjective code of conduct to control and police the members of their community.

Last I knew they even had a moderation team who doled out punishment without any due process nor any oversight of significance.

It's also quite common to see any comment here (and at certain other discussion forums) that doesn't paint Rust in a glowing light to get modded down, even when the observations made are completely correct, valid and legitimate.

As long as what you believe fits within the scope of what they believe, or corresponds to their narrative, then things are fine.

But beware if you happen to hold a differing opinion!

In fact I'm posting this using a throwaway account because I anticipate that members of the Rust community won't react well to my observations, and will respond with downmods.

I'm not very involved in the community, and I have little experience with the language, but my impression with the rust community so far has been very positive. It's one of the few places I've been where unproductive conversation is moderated gently but firmly. The only squashing of opinions I've seen has generally been for pretty trolling or very rude (from beyond normal bluntness) behavior. Maybe I've not seen the same things as you but my experience has been overwhelmingly positive.
What sorts of subjective control and policing have you seen in the Rust community, exactly? It's certainly stricter about enforcing things that HN or Reddit would let slide, but I don't see that as a bad thing, necessarily.

For that matter, what sorts of valid criticism do you see get downvoted? In my experience the Rust community is relatively honest about the language and ecosystem's shortcomings.

(comment deleted)
Disclaimer: I am on the Rust core team, although less active nowadays.

> Last I knew they even had a moderation team who doled out punishment without any due process nor any oversight of significance.

The oversight for the moderation team is documented here: https://github.com/rust-lang/rfcs/blob/master/text/1068-rust...

> It's also quite common to see any comment here (and at certain other discussion forums) that doesn't paint Rust in a glowing light to get modded down, even when the observations made are completely correct, valid and legitimate.

The moderation team isn't responsible for downvotes, so we should be careful to separate the issue of community moderation from downvotes on hacker forums. With that said, I should note:

• I rarely see comments critical of Rust downvoted on HN. I do reply to them if I disagree, but I never downvote them.

• On Reddit /r/rust, I rarely see comments downvoted ever—there's even a prominent warning not to use the downvote button for disagreements.

• I'm rarely ever on Reddit /r/programming at all, but my impression is that the moderation is all over the place no matter what the topic, so I don't see Rust as particularly special one way or another.

The Rust community is firm about technical correctness, like any good systems programming project. And, like any good and ambitious systems programming project, technical correctness is nonobvious and no one person is going to be right about everything all the time, because there's entirely too much to know and too much to keep track of.

Unlike many systems programming projects out there, the Rust community has an aversion to screaming matches, personality cults, and other attempts to enforce technical correctness via dominance tactics (not only because they're awful, but also because they don't work - see the things Ulrich Drepper got wrong in glibc, and Linus Torvalds got wrong in Linux, because people could not tell them that they were wrong). Responses to technically incorrect claims are usually firm but gentle, technically straightforward and non-insulting. If someone persists in those claims, they will not find a constant willingness to argue.

It is entirely possible that you have seen observations that were not correct, valid, and legitimate, made by people who are expecting to be told they are wrong in the ways that the old glibc community or the Linux community would tell them that they are wrong, and never took a quiet and friendly correction seriously.

As a member of the Rust community, I value your opinion, however I am not at all sure where you've observed the above described behaviour. The Rust community is the first one I joined without fears of being put down by the community because of my lack of experience.

The IRC channel is among the most helpful of any programming language I've seen so far, users.rust-lang.org gets multiple helpful responses to practically any question and the subreddit is very helpful for keeping up with the latest projects and take in community input.

I also observed that the Rust core team and community are very aware of its current shortcomings and are working on them with the community via the RFC process.

It's also very easy to contribute, you don't have to sign any CLA etc., and a member of the core team will even mentor you if you wish.

It would be helpful if you offered some concrete examples instead of being this generic.

I think I was being unclear since I think you're agreeing with me. As long as you're not insisting that you're right and everyone else is wrong, you will see a friendly and patient and helpful and vocal community. And, fortunately, most people are like that.

There are a few people who think they need to argue loudly and harshly to be listened to (possibly because they've learned that that works in other projects). Those are the folks who are likely to see little patience but also little argument; they'll get downvoted on Reddit and ignored on IRC. Which is good for the community, since any effort spent arguing with them can be spent working with people who are actually there to learn.

The easiest example to see might be when people show up on IRC picking a fight (whether against something Rust does, or technically in favor and deriding some other language). They'll get one reply saying "Yes, but there are always tradeoffs and other languages are great too", one reply saying they're off-topic, and no more engagement. Which is not to say you can't show up on IRC asking for a language feature! As long as you don't say that anyone who leaves the feature out is stupid -- and again, most people don't say that -- you'll get a helpful response.

I don't know the first thing about the Rust community and have no intention of ever writing a line of code in the language, but reading your post I'm reasonably sure you're in the wrong, whatever the situation was.
> Last I knew they even had a moderation team who doled out punishment without any due process nor any oversight of significance.

Member of said moderation team (and partially behind its design)

We have due process. See https://github.com/rust-lang/rfcs/blob/master/text/1068-rust...

Yes, the code of conduct is a bit subjective. That is why there is an entire moderation team, as well as core team oversight. I don't find anything harsh in the code of conduct, though. Anything specific you'd like to point out?

Enforcement will mostly be done only in blatantly obvious cases anyway.

Yeah, you're in the wrong.

The problem is that you believe that your opinion is the politically neutral one, and it isn't. It's just that the Rust community aren't a bunch of libertarians, which stands out considering how much of the tech community are, and how wildly that skews their perspective.

From a point of view outside of the tech industry, the Rust community don't do anything remotely unusual. Even much of the tech industry, outside of the SV reality distortion field, do much the same thing. They just try to keep garbage from the outside world from infesting the community and interfering with the work. Everyone else does that - it's really the only way to get anything done, short of having a totally homogeneous work environment.

Of course, a lot of you guys would prefer a totally homogeneous community. If Mozilla or the Rust community put you off... no big deal. It's not like there aren't plenty of others around who are quite happy to work with the Rust community because of their policies.

> But beware if you happen to hold a differing opinion!

If you hold a "differing opinion", and choose to take that into the Rust community with you... what do you expect? Keep your rubbish to yourself, and there won't be a problem.

FWIW holding differing opinions is fine. We try to keep discussions technical -- and differences in technical opinion are entertained. If a discussion does go into the social or political sphere (e.g. a discussion about the community itself, or the code or conduct), differences in the other opinions are entertained as long as the discussion is civil.

(Well, really, differences in any kind of opinion are entertained as long as the discussion is civil and your opinion isn't actively alienating someone else. "Difference of opinion" isn't something that affects your membership in the community at all, civility is)

Can you give an example?

I have some speculation as to what you're referring to, but it's easier if you just say.

(comment deleted)
Also check out Servo (an experimental web rendering engine written in Rust), which shares a lot of the Rust community, and is beginning to prove out some of its components for inclusion in Firefox.
Rust's IRC channel is amazing - supportive, thoughtful, and non-condescending. This is in sharp contrast to the Go one, which is an absolute cesspit.
I remember enjoying Go's IRC room early on, but it has gotten …more difficult. I fear this is inevitable and will happen to Rust, but it hasn't yet, which is an extremely pleasant surprise.
Thankfully (but still unfortunately), the Go community Slack does a great job of replacing the IRC channel with more civilized/productive discussion.

The IRC channel, like many, is often not a friendly place.

If this is the case, I think Go people should remove IRC and add Slack from this page: https://golang.org/help/
No! No more slack!

* Rocketchat * Gitter * Let's Chat https://github.com/sdelements/lets-chat * Baloons https://github.com/rickyrauch/Balloons.IO * Friends https://github.com/moose-team/friends * Chats https://github.com/acani/Chats * HackChat https://github.com/AndrewBelt/hack.chat * Jabbr https://github.com/JabbR/JabbR * qTox https://github.com/tux3/qTox * TorChat https://github.com/prof7bit/TorChat

I bet that they can be just as friendly using an open source application on golang-based kubernetes clusters.

I just made my first PR for rust and it's been a pretty positive experience.
Aside: I'm trying to improve the newcomer experience in Rust, so if anyone has any pain points they'd like to mention, or general things which they think could be improved, let me know!

This applies both to Rust the compiler, and Rust the general community.

Off the top of my head:

    Ansible
    FLTK
    SCons (when I used it. I wouldn't recommend the project, but I do recommend the community)
    Nim
    Python
    ffmpeg (mostly supportive, but expect you to be mannered too)
The open source world is flouring in 2015.

There is no shortage of amazing teams working on amazing projects on the web.

Its hard to single out just one of them - so its best if we could know more about your background.

If you are unable to find anything that is good enough then just start your own !

Do not be be demotivated - as long as you find it useful - someone else somewhere will also find it useful.

Even simple logging libraries have their audience.

So good luck !

Elm and Blockly.
PostgreSQL (I've always been hugely impressed by the team, though not myself a contributor).
Ditto. The community seems to have a remarkable ability to take the high road.
+1 for Postgres. It's one of the most awesome OSS project: great development team, community, large codebase (which is well organized and very modular), has a very good code and end-user documentation, always working with a significant number of important computer science problems and concepts (ranging from easy to very complex ones).

[Disclosure: I'm not a Postgres contributor myself. In the past, I had been working on Postgres core and related projects at EnterpriseDB (a Postgres company) for 5+ years].

This. I actually joined HN years ago just to praise Tom Lane for his outstanding support (I hope I remember this correctly).
Definitely agree. The PostgreSQL Community began my serious involvement with Open Source Software, about 15 years ago. It's one of the best groups I've ever seen, due to their patience, friendliness, encouragement of others, and willingness to share info/experiences for mutual benefit.

It doesn't hurt that being very good with PostgreSQL is useful on a CV too. ;)

The Jekyll folks are always nice and chipper. And disgustingly productive. :)
@antirez is all of the above to an amazing extent, however redis is one of the hardest projects to contribute code to from my own experience.

The community is awesome and very friendly and helpful though, and I reckon most of my contribution to redis has been as a community member helping out others or getting involved in discussions of redis' future, which is also a great way to get involved.

Openbsd.org
I've had very good experiences with the OpenBSD and the FreeBSD communities, too. As long as you do your homework and the answer you seek isn't in the documentation or FAQs, they'll go to the ends of the earth to help you out. This is really valuable for seriously hard problems.
You are kidding aren't you?
Check out #FreeSoftwareFriday on Twitter for praise of great open source projects.
Drupal's community is what got me into OSS, even though the language (PHP) community seems to be at a strange crossroads currently.

I've also been somewhat involved in Ansible's community, and it's been nothing but a positive experience so far.

It's interesting to compare some of the different communities; some seem to value technical competence over diversity, some UX over architecture, etc. It's probably easiest to dip your toes in the water and just make sure you can get help early on—jump into IRC or forums and see how people react to some initial questions you have about the project.

As a counter-point: I've found it impossible to penetrate the Drupal community. I have filed several tickets over the years, including patches, which have often gone entirely without comment for sometimes months. Including a bug report and patch against a core include file. IRC is sometimes helpful, but usually not. In my experience, it's just really hard to get any questions answered or bugs fixed in Drupal.
How recently was that? They made a big public effort during the Drupal 8 project to become more open, welcoming, and responsive, and it would interesting to know if that made a difference.
My most recent interaction with the Drupal community was today. I finally got a response on a couple of patches I submitted a few weeks ago (one committed, one got useful feedback, which is great!), and I followed up on a patch that I'd contributed that someone else used and found to resolve their problem (but still has no response from the maintainer, after a few weeks), and checked on that core include patch, which has no reply, even though I submitted a patch against D8 in hopes of getting a reply (I figured maybe all the core people were bored of Drupal 6 and Drupal 7).

So, no. The recent push hasn't changed much in my experience. It could just be bad luck, and my own inability to spend more time on the problem of introducing myself or being involved. Drupal will never be my core job or something I can spend significant time on. But, I've never had such a hard time getting feedback on patches before, with any still active project I can think of, and I've been submitting little patches and making bug reports against OSS projects for a long time.

If Drupal has a welcoming and helpful community I've had trouble finding where they hang out. It is definitely not in their issue tracker.

I am sorry. The issue tracker is a really vast place and it is indeed not the best place to start. I would recommend https://www.drupal.org/core-office-hours for example. However: right now is perhaps not the best time, we just had Drupal 8 out and everyone is resting. And there's Thanksgiving and then Christmas upcoming. I am in #drupal-migrate on freenode, however , very very often and looking for contributors to that effort :) #drupal-contribute is a good place too, it might look quiet now but try saying the magic words "I am new here and I'd like to contribute". Sooner or later (again, it's thanksgiving weekend) those words will conjure a welcoming guide :)
Thanks for the pointers.

I think this may be where part of the breakdown comes in. I don't want to be a "Drupal developer", don't want to devote huge amounts of time to the project (though I may release a couple of modules of the stuff I develop for my own use at some point), and don't necessarily want a guide (though someone that answers my questions about the incredibly complex abstractions in Drupal would certainly be helpful, I don't believe I'm entitled to such).

I want to fix bugs and add missing functionality that prevent me from launching my site, send the patches to fix those bugs to the people who maintain the component or module, and then move on to the next problem in my deployment. When I send those patches in, it's because I hope to never have to deal with the problem again. I've been casually poking my head into Drupal every now and then for years. I'd almost be willing to say the problem of casual contribution is worse than it was, say, 7 years ago.

That sort of casual contribution has rarely been an issue in the past with other projects; I've got patches in dozens, maybe hundreds, of OSS projects at this point. I don't mean to overvalue it and say this is priceless knowledge I'm imparting. Often it's just a couple of lines of code or a documentation correction, but each one adds up to a slightly better project. And, it's kinda how this stuff is supposed to work. Enough eyes makes all bugs shallow, that kind of thing. If I have to maintain a custom fork of several modules, and a piece of core, just to keep my site going, my experience becomes drastically less pleasant, and my reasons for using Drupal become less compelling. Much of the automation I have in place for staying on top of updates and such breaks down at that point.

I'm sounding grumpier about it than I actually am, probably, as I don't begrudge anyone not doing something for free. I'm happy to have all of these components that mostly work well together, and do useful stuff, for free. And, I'm willing to put in the work to make it suit my needs. But, when I see the suggestion that it's an excellent example of a helpful community, I have to take exception, as it's definitely not been my experience. Drupal forums and ticket tracker responses can be downright dismissive, at times, particularly when someone is coming from another system or framework and doesn't understand the Drupal jargon (which is vast, confusing, and often weird).

Again: I am sorry. This is something the project needs to figure out: how do you deal with thousands upon thousands of issues? Just of major issues there are more than a thousand! So if you post a random patch the chances are , alas, very high it'll be lost in this vast sea. Again: this is not ideal, hopefully we will figure something out.

OTOH, if you need help http://drupal.stackexchange.com/ is a good place to ask.

Believe me, I'm sympathetic. I work on a project with a million or so users, and a very small team supporting it. I'll try to find ways to follow up more directly on stuff like this. As I said, IRC (and the specific IRC channels of the modules I use, like drupal-commerce) has been occasionally helpful, and can occasionally nudge someone into looking at my tickets/patches. I've got a handful of new patches that I'd like to submit, will try to follow up more directly with the relevant devs, rather than just dropping them in the issue tracker and forgetting about them.
And this is where being a contributor pays off: if $random_guy comes in and says hey look at this patch, people might or might not and it might get in or might not. It's an entirely different thing when someone we know does the same, for so many reasons. One, there's the whole karma thing. Second, if I know this is not your first rodeo then I will be much more willing to invest my time in it (hint: time is the scarce resource hence the currency in open source world) because I'll know you already have coding standards, obvious API usage etc down pat.
All true...but also makes it not friendly to new people. ;-)
You need to give us a chance to be friendly. If you a drop a patch in a queue which has 10K other patches and then, as you said, move on then the chances of this patch being picked up is quite low.
I initially liked my experience with the Drupal community.

One of the things that drove me away (5+ years ago), beyond the direction the project took around Drupal 6 [1], was being stuck on Drupal.org for development.

In 2009, GitHub already offered everything the community would need, but instead developers were stuck with (poorly) custom made solutions. Last time I checked, it was still the case.

[1]: http://teddy.fr/2013/01/25/dropping-the-drop/

I have always had a mixed experience, and I think I mostly agree with that blog post, for the most part. I know our most recent migration to Drupal 7 (still ongoing, about a year after I started working on it in my spare time; it's the most painful migration I've ever worked on, including migrations across CMS and languages...this particular site has been migrated from OpenACS->Joomla->Drupal 6, all of those jumps were faster and easier than the jump to Drupal 7).

I'm very uncomfortable with the direction of Drupal (the willingness to break backward compatibility without credible paths forward for users being the most painful for me). I've always assumed mostly it's due to my own ignorance, but this blog post confirms some of that discomfort is not just me not knowing what's going on. There's been a big move of putting things into the database that once resided in code, and this makes it really challenging to figure out how anything works. The abstraction runs really, really, deep, almost absurdly so. Trying to figure out what makes a page happen is an exercise in frustration a lot of the time, as it has pieces that are in code, pieces that are in Views, and pieces that come from other mysterious locations (there's stuff that I just assume will always remain beyond my kin).

Drupal 8 seems to be further down that path. Certainly there are improvements, but it just requires so much knowledge to even begin to work on anything in Drupal that it's incredibly frustrating for someone that dips in every week or so, to add new functionality or fix a bug on my company website.

Earlier in this migration, and at several stages along the way, I've assessed whether I could move our site to something else with less effort and end up with something nicer (both for users and to maintain). I opted not to at several points along the path, but I'm still not convinced that was a wise choice, even as close as I am now to launching a D7 version. Frankly, I dread working on the damned thing. It's just not fun.

As for github, I don't actually blame an OSS project for not wanting to move into a proprietary source hosting platform. I have uneasy feelings about my own projects being hosted there, and plan to work on a gitlab or Phabricator or something else deployment eventually, so we are not beholden to a proprietary third party (github is a great product and they seem like great people, but so was SourceForge at one time).

Anyway, if there were some other thing (I don't like using the term CMS, because people often assume I'm wanting a CMS...when "content management" is effectively 0% of my use case for Drupal) that had integrated forums, ticket tracker, shopping cart with subscriptions and licensing, and a way to manage docs, and it didn't require mountains of custom code, I would have already moved away from Drupal. I've considered building something custom with a framework, but this isn't my core competency or interest; I just want to put some pieces together and sell and support the software I do want to work on full-time.

after almost a decade building everything with Drupal, i realized that only one site (a community blogging site) really benefitted from it.

From what I've seen of D8 it is going to be so different that it will almost certainly be cheaper to rewrite it in a simpler way (something like laravel for instance) than attempt the migration. For all but the most trivial sites, that is.

*edit: Oh, and are you aware of backdropcms? it is a fork of drupal 6 that is maintained.

https://backdropcms.org/

Spent too many hours with drupal over the years and I will stick with it, D8 has similar interfaces with D7 though the framework is totally revamped.

I also failed to find a good alternative, tried many but always came back to Drupal

Quite funny, but I had an experience with Ansible that's similar to the one the other commenter had with Drupal. I have a very trivial pull request[0] which I have been trying to get reviewed & merged since March. It's only around 20 lines of code, but I've been asked to rebase it due to merge conflicts multiple times. I did so, but nothing came out of it on either of those occasions.

[0]: https://github.com/ansible/ansible-modules-core/pull/901

Yeah, that's the risk with having a process with exactly one reviewer for a component. There really should be some way to have someone else take over if the main maintainer isn't able to complete it.
Seconded. It's not for nothing that drupal has the catchphrase "Come for the code, stay for the community."

But as others note here, it's not that the support forum gets particularly snappy response for every contributed module. It's the in-person community that people talk about. Drupal meetups, local events, and conventions, are far and away the most welcoming and FUN environment I've seen in any OSS project. We do large, mentored sprints for first time contributors, the top contributors are always happy to help out random newbies... And the whole experience is so friendly that we write musicals about it (no joke!) . I've encountered other communities that are friendly, but none that go as far as Drupal in the personal connection department.

I recommend looking into re:dash, which is an amazing and widely used data collaboration tool for your data. Arik Fraimovich is doing a great work with a growing community of contributors.

https://github.com/getredash/redash http://redash.io/

Disclaimer: I'm the founder of EverythingMe, re:dash was born in one of our hackathons but have since become its own beast.

Can I ask what are some of the differences between redash and a tool like Apache Zeppelin?
Visit https://openhatch.org/ -- they exist to match people with good open source projects. Good luck!
+1 They also help specifically label contributions that would be good for newbies to try.
FWIW, I've tried to find interesting things through this page a few times and have utterly failed. Maybe I'm missing something, but the search feature is a bad aggregator of issue trackers, without useful filtering or pre-selection.
Elixir and its ecosystem (plug, ecto and phoenix) has been above and beyond every time I've contributed. Helpful, patient and kind, and also very smart guys.

https://github.com/elixir-lang/elixir

https://github.com/elixir-lang/plug

https://github.com/elixir-lang/ecto

https://github.com/phoenixframework/phoenix

Agreed. Elixir is my first foray into functional programming and the paradigm is obviously different from OO.

The Elixir community on both IRC and Slack have been incredibly patient and helpful for a hack like me. Both in solving specific problems and teaching how to solve future issues myself the next time around.

+1. The community is a big part of the Elixir ecosystem.
Last April I decided to work on open source every day for a month. I saw a gap in the Elixir ecosystem (a driver for RethinkDB) and I just started hacking on it. The help and feedback I've gotten from the community have been fantastic. It's a community where I can tag José (the creator of Elixir) on a github issue for my driver and he'll chime in with very useful feedback. Imagine pinging Guido or Matz about the right way to do connection pooling and them responding. It's a pretty awesome community.
Another vote for Elixir. Very enjoyable community to participate in.
Find the projects that speak to you then check in on the communities. Contributing to open source is first and foremost _work_. A community can turn you off from participating, but the motivation to contribute only comes from the product.

And you might be surprised at the difference between what it's like to contribute to any random project compared to what a "news" blogger that needs to generate hits wants you to think the average project is like.

This is really the correct answer: Why do you want to participate in an open-source project in the first place?

If it's to gain brownie points for your CV, it's quite likely that you'll get nowhere, because that's a motivation right along with "earn money".

The difference to just getting a random software development job for earning money is that at the random job, you will be in a team where tasks will naturally flow towards you. In a random open source project, this will not be the case. So most people will not stick with it unless they have a better motivation for contributing to the project in the first place.

So try to find a project that you find interesting first. You should actually be able to find many of those if you're into software development, and then take a look at the communities yourself.

Another tack: look for employers that have already demonstrated a commitment to open source software / hardware. (This is, of course, a difficult chicken-and-egg problem for those looking to bolster a CV.)

I think starting at the language level, and then digging deeper for sub-projects in your interest sphere is a good strategy. I'm partial to the Perl and Python communities. Both have BDFLs that are kind people who lead by example. Projects associated with these languages often seem more accessible (IMO), and I think Larry and Guido deserve a lot of credit for that.

I'll also throw in a plug for jabber.org and telehash.org because Jeremie is one of the nicest people I've ever met.

edit: and exercism.io because Katrina is brilliant and dedicated to community building.

It was hard for me to find projects I found interesting enough to contribute to.

It wasn't until I had an overarching purpose that I found success. It took about 5 years.

This, so much this.

Working on Open Source absolutely requires individual contributors to be self-starting. New contributors who lack drive require constant direction and/or hand-holding, undermining the time/effort commitment of existing contributors.

Most Open Source projects invest a lot of time/effort coaching new contributors. If a new contributor receives the coaching but doesn't produce anything useful; it's a net loss for the project, users, and community.

I always tell people who want to start contributing to OSS to start with simple/easy tasks like documentation updates. It minimizes the negative impact of poor quality contributions and allows existing devs to identify and correct workflow inconsistencies during peer review.

The other growing pain is new contributors who bring their 'ideas' but put zero effort toward contributing. 'Ideas' are like assholes, meaning everybody has one. They're not particularly useful unless there's a person ready/willing to implement them. Even then, a new idea may not follow the intent of the project and/or its culture.

Endlessly discussing the 'future possibilities' of a project is extremely counterproductive and distracting to existing developers.

I have somewhat different perspectives on "ideas". People discuss ideas first because if they do the implementation first, there is a large risk of wasted effort because it "may not follow the intent of the project". Discussion is in part effort to divine the intent of the project.

As a concrete example, I implemented break and continue for OCaml compiler because having for loop without break/continue seems to me obviously a bad idea. Although I learned a lot about OCaml compiler internals, this went nowhere. I learned my lesson, and now I will certainly "endlessly discuss" possibilities of break/continue first, without writing a single line of code. In my opinion, berating people for this is placing undue burden on contributors.

http://caml.inria.fr/pub/ml-archives/caml-list/2008/04/ce14d...

An idea followed by an implementation is awesome and exactly what OSS projects need from contributors.

"I learned my lesson..."

I read the mailing list and don't see how that was a negative experience. Only one of the contributors had an unfavorable response.

Even if they don't implement your code as-is, it looks like you had a good idea including a good implementation that led to a lot of productive discussion.

Only one of the contributors had a strong objection and despite that, the conversation continued.

Don't take it personal if your code isn't directly incorporated into a project. Despite that, your contribution led to further discussion and helped better focus the intent of the project.

Working on an OSS project is very much about collaboration. Code contributions may not always be incorporated into the codebase, especially on projects like ocaml that have a specific focus and changes have far-reaching impacts on the userbase.

That's not a bad thing. You did well.

:cringe: Apparently I, need to expand the comment text field and re-read my comments before posting. Hopefully, you could infer my meaning from the word vomit.
I understand where you're coming from but the open source community as a whole has a reputation (though whether it deserves this is another question) for being a potentially toxic thing to interact with.

I guess I read it as implicit in the question that they're looking for a bunch of open source projects that will be supportive of their contributions to then select one that they find interesting in order to avoid picking an interesting project, working on an issue couple of days only to be told to go %&@# themselves because the PR isn't formatted correctly or something.

Some big projects (Fedora, OpenBSD etc.) are deserving of their reputations for having toxic communities.

I've never experienced such condescension online as from the pricks on the Fedora IRC channels.

I spend my life first and foremost in a community. I think it makes perfect sense to look for a good community first and then check in on their project.

That said, I've noticed that all of my favorite communities are centered around good work, and that good work makes it easy to find and share joy. A great community isn't going to be working on something stupid.

Theforeman -Foreman is a complete lifecycle management tool for physical and virtual servers. theforeman.org github.com/theforeman
React. I'm constantly impressed by Ben Alpert's[1] patience and response time and ability to answer questions all over the internet.

1. http://stackoverflow.com/tags/reactjs/topusers

I appreciate you saying that. Thank you.
How do you do this?
I try to be helpful whenever I have a chance. When I first adopted React, my coworkers were frustrated that whenever they Googled for errors they didn't find anything, so I committed myself to writing answers to all the reactjs questions on Stack Overflow for a few months. I do my best to be helpful when responding to issues too -- though I've had less time to spend on maintaining our GitHub repo lately and consequently been less helpful.