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 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.