Item — HN Reader

How does it get to this stage where someone has to write up a hostile post to get across this point? Have the maintainers been too nice/polite and/or accommodating and now resent it in face of requests they can't fulfill (and the backlash it may have caused)?

I'm genuinely puzzled as to why bluntly refusing a feature, contribution, etc they didn't like hasn't worked for them. It's worked just fine for my limited experience in maintaining FOSS projects. Perhaps there is a scale aspect that I'm missing here.

4 comments

Not sure which "hostile post" you are referring to, as I don't think the submitted article is hostile at all. It's just very clear in what the author is trying to get across.

But anyway, this is how we got to the point of Hickey writing this post:

- Heavy Clojure User received bunch of feedback from friends and colleagues asking why something hasn't been fixed yet in Clojure core

- Heavy Clojure User sees that bunch of stuff hasn't been fixed, so they take it on themselves to fix these issues and submit patches

- The workflow of "Submit patch -> Have Hickey review it and deny it -> Make changes -> Wait for Hickey again -> etc etc" was too slow for the Heavy Clojure User

- So Heavy Clojure User made their post describing "How to contribute to Clojure", blaming the core team for not working tightly enough with the community and spending enough time reviewing/accepting patches

- Hickey publishes this post titled "Open Source is Not About You" not entirely aimed at "Heavy Clojure User" but the community at large, while still being a reaction to that post by Heavy Clojure User

- Heavy Clojure User apologizes for the initial post, for tying Clojure with their own identity and explains a period of self-reflection has begun.

> as I don't think the submitted article is hostile at all

Tone is lost in text and I don't have much background. If I was thinking of contributing to Clojure, this post is reason enough to stay away from it.

Based on your explanation, I think Hickey should have simply ignored the user's post and let that be the end of it. I mentioned "blunt" response to individual contributions. That is quite different to a blanket statement with a "we don't owe you s... - f... off if you don't like it" vibe.

> If I was thinking of contributing to Clojure, this post is reason enough to stay away from it.

Without wanting to sound flippant or rude, I think they'd be cool with that. They're talking about contributions to the core language here. Not fixing typos in a README.

In mature projects like this, all the low-hanging fruit is done. You can't just take a notion some weekend and fire off a useful pull request. It requires an investment. To make a good contribution to Clojure you have to....

  - clearly define the problem that needs to be solved
  - get other people on the core team to agree that it needs to be solved
  - document a number of ways to solve it, discuss with the community which one will work best
  - let these ideas stew for a while, people might change their minds

The above constitutes 95% of the work and would typically take months rather than days. Once all that's done, coding up the implementation is the easy bit.

> Not fixing typos in a README.

That's a detail that, even if specifically was mentioned, would be overshadowed by the main sentiment.

The blanket statement is correct, though. It may not be couched in a palatable way, but only in that it doesn't spend lots of words on how lovely everyone is and how few people it is addressing. It just says what's true and leaves it at that. If you'd rather not work in that environment then that's reasonable, but I think it's a little refreshing compared to what I normally read from big OSS projects.

Sometimes directness comes across as hostility. Telling someone they aren't entitled to something can come across as hostile, even though it isn't and is merely the truth.

It's a typical pattern that I've seen in FOSS projects over the last decades. Somebody writes something cool, publishes it, is initially happy about adoption and positive feedback, and then people start to demand more and more of them. Fix this thing, add that thing, here is my code, when are you finally going to merge it, why are you not responding, you are not respectful of me, etc. etc. Then a mix of burnout and resentment happens and the more bold ones issue such a statement. Others just abandon their project and are never seen again.

It's very sad, and it's rooted in a basic misconception of what FOSS actually is. That's why such posts are important to educate people, even if it sounds drastic.

> it's rooted in a basic misconception of what FOSS actually is

I don’t think so. It’s rooted in the expectation of open source: that code is provided with the intent of being useful. But if you never merge patches, that isn’t very useful. There’s a forking cost and people are aware of it so it’s just natural behavior.

If it's not useful why are they using it?

Lock-in, usually. Using a tool that has it as a dependency. Also, if it's un-useful, they probably won't be using it for much longer since it will likely be forked. But that takes effort, so it's easier to ask for the original dependency to just be updated, especially if the patch has already been submitted (which is like 90%+ of the work).

> It's a typical pattern that I've seen in FOSS

You'd think that people working on FOSS are aware of this pattern and watch out for it. But seemingly not!

Is there any reason that you think being aware of the pattern is enough to solve it, or feel no consequences from it? I think people are aware of the pattern (it's not hard to notice) but that doesn't solve the issues it creates.

There may be another thing at play too. Many projects are presented as being useful: “I built this great thing, you should use it!” Open Source or not, this gets to be a promise people will be held accountable for.

If instead a project is described as “I built this thing for me. Here’s the source. Please don't trust me, or my code, with anything valuable” expectations can be better aligned perhaps.

There can of course be middle grounds. “I wrote this useful code. If you need me to be your project manager for it, here’s how you can pay for that privilege”

> If instead a project is described as “I built this thing for me. Here’s the source. Please don't trust me, or my code, with anything valuable” expectations can be better aligned perhaps.

Every open source project states this explicitly. In the license. Usually in all caps. Wanna see?

MIT license has:

--- THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. ---

See? "No warranty of any kind." I.e. "don't trust this with anything valuable". How can this be more explicit?

GPL:

--- 11. BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION. ---

See? "The entire risk as to the quality and performance of the program is with you". How can this be more explicit?

Nowhere does it state that the author is obliged to provide support, reply to issue reports, accept merge requests, or is even nice to anybody. It's great if they are, and I appreciate such projects as well, but nobody is entitled to that. So please don't assume it or berate people if you encounter the opposite. This builds false expectations in others who don't know any better. We need to help each other out to build proper understanding within the community.

That’s legalese boilerplate. It might be useful for actually legal disputes, but I don’t think it has much use for public relations. It could be prudent to have similar sentiments included in more familiar ways in the regular project description.

But perhaps more importantly, if you really feel that your software “has no implied fitness for a particular purpose”. Don't do keynotes and conference talks claiming the opposite.

I think there are at least two factors at play: genuine disagreement about what open source is, and a variant of the Eternal September effect.

I’ve said it before: “entitlement” goes both ways. Treating users of your software like the enemy is no way to behave, whether it’s open source or not. If you don’t like your users - maybe it’s time to take a break from software development?

Based on this post, you get the impression that Hickey think Clojure users are his enemies? I didn't get that impression at all, and I also know that Hickey sees Clojure users as friends, receives feedback from many in the community, and Clojure is open to community contributions, although differently than many other projects are run.

Perhaps not Clojure, but there are other projects where this is an issue. Users are treated as a burden: the regular response to a bug or request is "well why don't you do it yourself then". I don't really want to start a flame war so I won't name names, but I have seen it. Though I'll say it is thankfully rare.

I disagree with a good part of the substance of the article. Publishing open source software incurs a self-imposed obligation to do much of what Mr. Hickey says nobody is entitled to, in my opinion. If you don't want that responsibility, don't publish.

I don’t see how. The license explicitly says otherwise.