Open Source is Not About You

OpenSourceIsNotAboutYou.md

Open Source is Not About You

The only people entitled to say how open source 'ought' to work are people who run projects, and the scope of their entitlement extends only to their own projects.

Just because someone open sources something does not imply they owe the world a change in their status, focus and effort, e.g. from inventor to community manager.

As a user of something open source you are not thereby entitled to anything at all. You are not entitled to contribute. You are not entitled to features. You are not entitled to the attention of others. You are not entitled to having value attached to your complaints. You are not entitled to this explanation.

If you have expectations (of others) that aren't being met, those expectations are your own responsibility. You are responsible for your own needs. If you want things, make them.

Open source is a licensing and delivery mechanism, period. It means you get the source for software and the right to use and modify it. All social impositions associated with it, including the idea of 'community-driven-development' are part of a recently-invented mythology with little basis in how things actually work, a mythology that embodies, cult-like, both a lack of support for diversity in the ways things can work and a pervasive sense of communal entitlement.

If you think Cognitect is not doing anything for the community, or is not listening to the community, you are simply wrong. You are not, however, entitled to it being the effort, focus or response you desire. We get to make our own choices as regards our time and lives.

We at Cognitect have to show up to work, every day, to make a living. We get no royalties of any kind from Clojure. We are in no way building Clojure for profit. Far fewer than 1% of Clojure users are our consulting or product customers, and thus contributing to our livelihood.

We take some of what we earn, money that could e.g. go into our retirement savings and instead use it to hire people to work on Clojure and community outreach, some full-time. To be honest, I could use that money in my retirement account, having depleted it to make Clojure in the first place. But I love working with the team on Clojure, and am proud of the work we do.

Alex Miller is extremely attentive to and engaged with the Clojure community. He and Stu Halloway and I regularly meet and discuss community issues. Alex, at my direction, spends the majority of his time either working on features for the community or assessing patches and bug reports. I spend significant portions of my time designing these features - spec, tools.deps, error handling and more to come. This is time taken away from earning a living.

I am grateful for the contributions of the community. Every Clojure release incorporates many contributions. The vast majority of the user community doesn't contribute, and doesn't desire to contribute. And that's fine. Open source is a no-strings-attached gift, and all participants should recognize it as such.

The Clojure process is not closed, but it is conservative. I think Clojure benefits greatly from that conservatism, in contrast to some other projects with high churn rates and feature bloat. If you disagree or imagine otherwise, that's too bad. It's my life and I'm not going to spend it arguing/negotiating on/with the internet. Write your own things and run your own projects as you see fit.

We can always do more, but it is specious to claim that the core team is standing in the way of meaningful contributions to Clojure, as opportunities abound: in library development, outreach, training, tutorials, documentation, giving talks, tool building etc.

And yes, on patches to core. Did you know that most patches/issues have poor problem statements, no description of the plan (read my code!), no consideration of alternatives, no tests, no designs, and are ill-conceived and/or broken in some way? Community efforts to triage matter a lot in moving things forward - thanks Nicola, Ghadi and many others!

The time to re-examine preconceptions about open source is right now. Morale erosion amongst creators is a real thing. Your preconceptions and how you act upon them are your responsibility and yours alone. I am not going to answer for them or to them.

If the way Clojure works isn't for you, a process which produced Clojure in the first place, paradoxically, so be it. I'm sure you know better about the one true way to write software. But kindly don't burn the community down on your way out, with self-serving proclamations. Yes, everyone is entitled to an opinion, but, tragedy of the commons and all that.

I encourage everyone gnashing their teeth with negativity at what they think they can't do instead pick something positive they can do and do it.

Rich

p.s. My partners and coworkers at Cognitect were not consulted regarding this message - I am certain they would have dissuaded me. These opinions are mine alone.

p.p.s. I think the vast majority of people in the Clojure community are wonderful and positive. If you don't recognize yourself in the message above, it's not for/about you!

I think we can learn something by seeing it from a larger perspective, and recognizing that a conversation regarding the balance between them
Completely agree. I'm constantly amazed how people don't even try to gain that perspective. People (maybe not all but many) have good intentions, they are coming in from different directions. Being polarized is just wastage (attention, time, resources etc).
Good to see that is not the case here 👏

Clojure is indeed a gift, and a very addictive one at that 😄 Thank you @richhickey for the clojure and all the meta talks. Some even provide great oneliners 🤣

This blog post is nice, but could have been much shorter. Really.

That's true. Opensource doesn't mean help you without any requirements. The community only exists in those who contribute themselves. Although open source brings so many valuable things to companies or society. Open source just opens the source and helps share the intelligence of the researcher.

Thanks for this post.

I agree with all your points.

I don't have other words to say but this one. Don't need to explain in commenter's own thought, or any other comments. This is just a declarement. No need to comment. (So this is not a comment, just a comment to other comments.)

Hey Rich, I don’t use Clojure but I have found this post helpful as a maintainer of much smaller projects. So thank you for gifting us with this explanation as well.

Thank you, Rich

I cannot possibly understand the people that try to force their opinions on something that's not under their control. If you don't like some Clojure features - well fork Clojure and make them. You didn't pay for the thing and you weren't promised anything - it's as simple as that. Good or bad - the choices are not yours to make. Learn to respect other's people's effort, decisions, opinions, lives.

Thank you for Clojure and all the brilliant ideas. Those are truly a gift - and much more than that if you ask me, as they changed my whole career.

Thank you for sharing the heartache that comes from folks not living their lives. The human developmental model is a double-edge sword which is very sharp on both edges. Most of us can't get past dependency. Socially and personally, we pay a very high price for our 9-month + 25-year-+ internship.

Your suffering is real. We can better share it now. Thank you for trusting us with it.

edit because a quote came to mind:

My mom said something. “You can lie down for people to walk on you and they will still complain that you're not flat enough." Live your life.

Almost 20 years in open source and Free Software, couldn't say it better.

I assume that strict linkage between read access to repo and access to create issues in GitHub is part of the problem... it creates illusion that if I can read the code therefore I can have a vote in its development

This thread has been a very interesting read. Unfortunately, 98% percent of commenters (and therefor likely readers) have actually missed the forest from the trees. It seems that everyone has just read the OP and assumed this is about pesky un-involved people demanding features and fixes etc, or contributing bad patches and being upset about rejection.

It was actually born out of the misaligned expectations between the project founder / leader and one of its big contributors, who's projects have been influential in the larger community, where the leader has chosen to publicly lump that big contributor in with all entitled users, after said big contributor likely got over-emotional in a previous internal-to-us struggle and decided to leave (not that he was a part of the "Clojure team" as it were)...

So, if you are coming here as an "A HA, someone already wrote the definitive catch-all response to entitled brats in OSS", that isn't what this actually is. You probably shouldn't link to it for that purpose either.

I don't even know the backstory here but appreciate the message. It resonates with me as I decide whether or not to open source a project I have been building with a small team over the last 18 months. Thanks for not consulting the team, or letting them dissuade you from posting this.

I think a core issue about that topic is, that its easy to combine the idea and the promise of an 'open source community' and what comes implicitly with it - communication, social dynamics, productivity, and more.

We are used to how communities work - and then somebody puts out source code and we silently assume they want all of that.

And that they are capable to do it, and that all the time.

Since in order to work within a community, as certain amount of responsibility, accountability and there I say it, productivity is needed.

Sure, nobody is entitled to this, and I certainly see it some people develop some kind of entitlement.

And also true is, that a community can only work once they have people on board, that contribute to it:

And an open source code, or simply an active Github account, certainly appears to promise someone community.

Maybe we should be conscious about the distinction between a community and code.

love this. great rant

I know why you wanna hate me
Cause hate is all the world has even seen lately 🎵😁

Thank you for your contributions to Open Source.

All social impositions associated with it, including the idea of 'community-driven-development' are part of a recently-invented mythology with little basis in how things actually work, a mythology that embodies, cult-like, both a lack of support for diversity in the ways things can work and a pervasive sense of communal entitlement.

This sentence strains the truth. Open Source (uncritically) inherited the ideology of Free Software, and "communal entitlement" was very much on Stallman's mind:

I went to his office and I said, “Hi, I'm from MIT. Could I have a copy of the printer source code?” And he said “No, I promised not to give you a copy.” I was stunned. I was so … I was angry, and I had no idea how I could do justice to it. All I could think of was to turn around on my heel and walk out of his room. Maybe I slammed the door.

All social impositions associated with it, including the idea of 'community-driven-development' are part of a recently-invented mythology with little basis in how things actually work, a mythology that embodies, cult-like, both a lack of support for diversity in the ways things can work and a pervasive sense of communal entitlement.

This sentence strains the truth. Open Source (uncritically) inherited the ideology of Free Software, and "communal entitlement" was very much on Stallman's mind:

Of course, entitlement is not a new idea, being older even than Stallman :) 'Entitled to what?' is the question that matters. Entitlement to participation in a project was never part of Stallman's four freedoms, and Raymond's "Treating your users as co-developers is your least-hassle route to rapid code improvement and effective debugging." merely indicates that he (and others) thought that was a good idea, with successful exemplars.

Yet rights to project participation have never been part of the Open Source Definition, even if allowing such participation was the practice of its proposers. OSI's OSD is strictly about rights to consume/derive. As is often the case, modest encouragement by thinkers gets taken to extremes by their devotees. Examples become canon. Advocacy turns into dogma, then entitlement, like wine into vinegar.

Yeah, I mean, I guess you're concerned with rights consumers might attempt to assert over you as a maintainer—concerned specifically with rejecting them! 😅 I've found RFC 2119 helpful to express hitherto implicit OSS social contracts. I explored this in the context of the concept of a "gift economy" (I was trying last year to make videos vs. writing, forgive me), but then shifted to the term "gift community" under the influence of PHK. I've had it in mind to write a Gift Community License (GCL) that spells things out, along these lines:

This software is offered in the spirit of the gift, without warranty of any kind, etc., etc. Here are my expectations (the terms MUST, MAY, SHOULD, etc. are to be interpreted according to RFC 2119):

1. You MAY do whatever you want with it.
2. You MAY offer to reciprocate for the gift with your own gifts of feedback, product, labor, money, etc.
3. You SHOULD reciprocate meaningfully.
4. I MAY accept or reject your reciprocal gifts.
5. You MUST include this license with any redistribution.

Roughest of sketches. Offered under the terms of the GCL. 😏

Uh-oh ... https://gist.github.com/chadwhitacre/b3671c3a89855292f8f44c77f3eb9324

I get a chuckle out of seeing this thread pop up every 6 or 7 months, as yet more people weigh in. Seems like 8 years later it still strikes some sort of chord with people. I would recommend that people read the post that prompted this response.

Having just gone back and refreshed my memory, I find it fascinating that this post chain is so opinionated and philosophical considering the original statements. Essentially what I said in my post:

1. All contributions to Clojure must go through Rich (was true at the time, not sure if it's true today)
2. Rich is human and can only do a limited number of things in a day (pretty sure this is still true, barring some sort of eldritch ascension)
3. Instead of optimizing for ticket throughput, or acceptance, it's optimized to require the least amount of input from Rich, while still giving him full control.
4. I considered this process to be a bottleneck and a strain on the health of the project.

The comments about people "owing" something to open source contributors, or even framing this as "it's not about you" is rather orthogonal to my original complaint. Yes it isn't about me, but that was never my claim. My claim was that the majority of people writing patches for Clojure were wasting their time because if the problem wasn't well laid out, concise, and able to be expressed in a single paragraph, it never had a chance of being accepted. And often when patches were accepted they were allowed in months or years later. I remember puzzling at a Clojure changelog that mentioned me as a contributor, as I hadn't submitted a patch in recent memory. Turns out it was a patch I had made 2 years before that release.

Now, almost a decade later, I find myself thinking about this again. I don't think we need to try and constrain open source to a single definition. Some projects work well with a "merge first, ask questions later", others likely need a stronger guiding hand. Much like how we had to differentiate GPL3 OSS from MIT OSS, we likely need to view OSS projects as operating over a spectrum. On one end you have the anything-goes-organically-grown projects that may break at any release, but they innovate quickly and get new ideas out in record time. On the other side are the more ivory-tower approaches, the one person pet project, the polished statue. These projects won't change much over time, but that can be a benefit for many types of projects.

If this chain of posts makes people stop and reflect on the projects they want to spend their time on, and the types of communities they want to build, then I think it was a success.

Now, almost a decade later, I find myself thinking about this again.

Hi Timothy, I hope you are well. I'm sorry that you think, and others might presume, that this gist was a direct reply to you or your post. Yours was but one straw of very many. I was certainly under a lot of stress when I wrote it, but it served as a useful release valve (I didn't quit :). I think it started a broader conversation about, and awareness of, the challenges of being a project creator and steward.

I will push back on the Clojure process being "optimized to require the least amount of input from Rich, while still giving him full control". That's not the case. It's a process oriented around increasing confidence. When we write software, we want to be confident it will work, and when we accept patches, we want the same thing.

Within the Clojure core team, a patch is actually the last thing we want from each other. A patch is something you make when the work is finished. A submitted patch on a ticket with only a symptom (if that) leaves all the work to the reviewer, because the code itself rarely contains a root cause analysis and almost never an accounting of other solutions considered with a case for the chosen approach. It can be much more effort to do that work starting with someone else's code than from scratch. So all a patch with no accompanying documentation of work is doing is saying "work on this thing now because I've made a patch for it" vs working on things for which there aren't patches but might be of higher priority/interest for the maintainers.

I agree completely about project development approaches forming a spectrum. And the closer you are to the bottom of the stack the more deliberate you need to be IMO. Unfortunately for many devs (to be clear, not you Timothy), moving from symptom to patch-that-makes-it-go-away is "work" and the patches one sees reflect that. Soon, that kind of symptom-elimination coding will no longer be the province of humans. Yet the challenge of confidently designing and developing reliable, flexible systems will remain, and it will still be the work, primarily, of considering problems and solutions, and only at the end, code and patches.

p.s. Thanks for your work on core.async! It remains a valuable and widely used contribution.

Rich! It's been awhile, good to converse with you again. In the past 8 years I've forgotten exactly why I thought this was in direct response to my post, perhaps it was something to do with the timing of it. At any rate, it's not something I've held a grudge over, on the contrary, it's a counter point I've come back to when reasoning through discussions about OSS. Over the years there's been more than once where I've looked up from dealing with some people-conflicts in my projects and said "oh! this is what Rich was talking about back in the day".

Point taken on the push-back. I can certainly see where careful, intentional, improvement can be seen as bottle-necking on an approval process. And if the primary problem to be solved is design, not implementation, then a patch can hinder rather than help. As you mentioned it's also highly dependent on the type of project, and languages are unique in being at the "bottom" of the tech stack.

Thank you for the kind words, and all the work you've put into Clojure. This past year while on a roadtrip, I did a re-listen to "Simple/Easy", "Language of the System", etc. Those talks continue make me think about my work and challenge me. As such, they have been life-changing.