Setting expectations for open source participation (2018) | Hacker News Reader

Setting expectations for open source participation (2018)

snarky.ca

39 pointszbentley13 comments

I am generally highly sympathetic to this sort of article because open source can be so thankless, a ton of work, and people can be jerks. He makes some excellent points.

A couple of times though I got the impression that he has some responsibility for some of the hurt he experiences. At one point he says it is hurtful when someone writes an article pointing out the “dumb” parts of python. While the word “dumb” may be less than ideal, there are by his own count 90 other committers besides him and 7 million total python contributors. Maybe he’s taking the criticism too personally.

Or here, he says pointing out something is “broken” in a bug report is hurtful to him:

>Assuming your contribution makes sense, you also need to pay attention to how you communicate. It is not uncommon for someone to submit a change and point out how they are trying to "fix this broken/wrong thing". I don't think people necessarily intend to be mean, but realize that when you say something like that you are telling me I failed and you're trying to clean up my mess. The put-down of saying I did a bad job does not motivate me to want to review your change, nor does it motivate me to want to contribute further if my work is just going to be viewed as bad.

In my opinion, if someone talks about your work in a non personal way, and you take it personally, that’s on you. In any field we need to be able to criticize work in a way that is hopefully kind but also honest. I think complaining about the word “broken” in a bug report is over the top and potentially creates unrealistic expectations that lead to a paralyzing inability to communicate clearly.

python-dev is full of double standards. The inner circle continuously complains about "being attacked" and "hurt" while they are doing the same and worse to other people.

This article from 2018 is part of the movement that paved the way for the CoC power grab and consolidated the power in the hands of a few people that do not deserve it.

Today a famous and well respected core developer was suspended. Presumably, that is why this this old article made the front page of Hacker News right afterwards.

https://discuss.python.org/t/three-month-suspension-for-a-co...

I posted the article, but did not know about that event until I saw your comment.

To me, it's quite interesting and thought-provoking to see the words "may" and "could" being used prominently in the reasoning.

this all sounds pretty reasonable and, honestly, a given.

> you should view open source as a series of kind acts people have done altruistically

> just because open source software is free for you doesn't mean someone else hasn't paid some price on your behalf to get you that code

Maybe this is directed towards people who don't write software?

Possibly. I don’t know if it’s always the folks who don’t write software, but any open source repo of a decent size will attract some people who will act entitled and demand you do things at their direction.

Often this does come from people that don't write software. Though some of the more grading experiences in this area I have had did come from people with at least some experience in writing software. Where they used that experience as a sort of argument as to why their demand should be met as swiftly as possible.

Do you know what happens if those "demands" are met with a response of: "I don't like your tone, please rephrase this as a polite request and I'll consider it"

There are ways of setting boundaries around behaviour in real life. Can maintainers use those methods for this?

> "I don't like your tone, please rephrase this as a polite request and I'll consider it"

Phrased like that, I feel like things would only escalate. But in specific situations like the ones I mentioned, I would go for something like "As you know from your own experiences, software development takes time and effort and this is a volunteer project. I do take suggestions and issues seriously and am happy to discuss them in a constructive way. This discussion at the moment does not feel like such a constructive discussion. I'd be happy to continue the discussion from a more constructive place" and leave it at that. It is a bit more explicit than just "tone" and also makes it more clear as to why they might want to take their behavior more into consideration.

Overall, yeah I think maintainers and the setup of the project do influence a lot of how people interact with them. I actually left a comment about that somewhere else in this thread: https://news.ycombinator.com/item?id=41188425

I think it is difficult to make general statements about all "open source" projects, because there seems to be at least 3 different types of open source projects:

1) Small projects, owned and maintained by a single person, with maybe a few random contributors.

2) Medium-sized projects maintained by handful of developers, without much organizational structure.

3) Large, almost enterprise-scale, projects used by thousands or millions of downstream users, maintained by dozens or hundreds of developers, requiring fairly complex organizational structure.

The article says that "instant you get that first contribution to your code, it becomes an open source project with an open source community of two", and the purpose of the project changes to "collaborating on the maintenance of the project".

For me, absolutely not. For most of my personal projects that I have open-sourced, I have no desire to migrate from a Type 1 (small, personal) project to a Type 2 (medium-sized, multiple-maintainers) project.

I accept PRs on a case-by-case basis, but I usually reject a vast majority of them: they are often buggy and incorrect, or they don't match the purpose and design of the project, or they are correct but severely incomplete (e.g. missing edge-cases, missing tests, missing documentation, etc). I have discovered that it usually takes me more time and effort to code-review the drive-by contributions into an acceptable state, than to just implement the feature myself.

On the other hand, for Type 3 (large, enterprise-scale) critical projects which affect numerous other parties, there is probably a higher level of implicit and social expectations that the project will handle bug reports and feature contributions from 3rd party contributors in a reasonable manner. The development process of a large project probably shouldn't rely on the whims and emotional state of a single maintainer on the project.

With regards to "kindness", which the article mentions a few times, I think for small projects, it might be reasonable to expect the kindness of the community. But for large projects, it is unrealistic that "kindness" will scale to thousands or millions of users. Too many people are too narcissistic, thoughtless, cruel, or all of the above.

In summary, it seems to me that the expectations and the dynamics of an open-source project varies quite a bit, possibly depending on the size and character of the project.

> But for large projects, it is unrealistic that "kindness" will scale to thousands or millions of users. Too many people are too narcissistic, thoughtless, cruel, or all of the above.

While it is sadly not to be expected, I don't think it should prevent projects from at least trying to cultivate it. One thing I have learned when dealing with large communities over the years is that it certainly is possible to cultivate a more general atmosphere that greatly reduces the amount of unkind/aggressive interactions.

Part of the strategy to make that work is to keep talking about it and keep reminding people. People tend to get wrapped up in their own mind on the internet, for a majority of people being reminded of the fact that they are interacting with other people is often enough. So you need to make sure that as a project you have these things explicitly stated in places like contribution guidelines, on top of issue templates, etc. In addition to that, contributors and project owners need to be seen talking about these things. It might seem a bit childish, but things like a "hey, I'd be happy to continue talking about this issue you created but in a more constructive manner" from contributors help a lot as well. People tend to see that and notice that there is a clear expectation from the project. And of course, articles like this one actually are really important.

And to be clear, it is never going to perfect, but in the long term it will be a lot better for contributors and owners than without any "community training" on these sorts of things.

I’m in the same camp. If I do something I find interesting and make it open source, it’s because I’d like to do this work out in the open, or someone might benefit from it, not that I am necessarily seeking out collaborators.

Plus if you do GPL, accepting that first contribution is giving away the easy path should you want to relicense in the future.

Reply on news.ycombinator.com