One of the main takeaways personally from this post, is the unique position Clojure (and other lisps) are in, where language additions can be done as libraries instead of changing the core of the language.
Other languages don't (always) have this possibility.
Taking TypeScript as one example. If 20% of users want to be able to do something in TypeScript that the language doesn't support, they either can try to get the change into the core language, or live without it (or fork it). If it changes, it'll change for everyone using TypeScript
But in Clojure (lisps in general), you don't have this restriction, so modifying the language for your own need, becomes a lot easier. Lots of work on Clojure is simply done in libraries, as it's possible and doesn't impact the core of the language, which everyone shares.
The thing is, it’s technically present, but culture is another matter. I maintain a Clojure project that ran using a number of interesting and convenient macros. In practice, it made things harder for people to read and was unidiomatic. If you want anyone else to use or modify your code, you’d better stick with Hickey’s vision.
Absolutely, and this is being completely ignored in the whole discussion. We’re utterly dependent upon Clojure “core” for anything to become idiomatic; saying that it’s possible to make anything outside of core and do your own thing is about as productive as saying “just fork it” about opensource projects.
I think that this post by Rich Hickey actually made me completely lose faith in Clojure’s stewardship after about 5 years. It basically signalled very strongly “we’re not interested in listening to the community”, which is fine, but that doesn’t align very well with how long-lived, successful opensource projects are managed.
And I say all this as someone who was very actively involved in some of Clojure’s largest opensource projects.
I just picked up clojure as a hobby project outside of work and I’m enjoying the language in general so far. I have to say that reading this rant gives me a bit of doubt about continuing.
I actually agree with most of what this guy is saying, but the delivery is not good.
Clojure, the language, and Rich Hickey, the vision, have had a tremendous impact on my programming career. Transformations of data as the primary building block for writing code was such an enlightenment. I absolutely encourage you to continue your endeavor of learning Clojure, as it’s almost guaranteed to be a net positive.
It’s just the stewardship of the language that is my biggest problem. It’s very anti-community (as evidenced by this rant), and in general there is a tendency of “elitist” mentality the more you get into the core community.
If you’re able to ignore all that, and just do your own thing, you’ll be fine.
It’s an interesting road, and I like Clojure plenty, but ultimately it’s a cul-de-sac. And the reason it’s a cul-de-sac is pretty heavily laid out by the original post.
I don't know, the community in general tend to use macros that are well written. I keep seeing core.async being used (`go`) in Clojure projects, and also various macros for writing HTTP servers (compojure being a popular one which main code interface is a macro `defroutes`).
ClojureScript projects also routinely add support for making asynchronous code look synchronous (like `async/await` in vanilla JavaScript) via macros. shadow-cljs's `js-await` being one of the well-written ones: https://github.com/thheller/shadow-cljs/blob/49fb078b834e64f...
I'd say if adding a macro makes things harder to understand, you probably need to re-evaluate if you really should have a macro here, or the interface of the macro.
Yeah, there’s a couple of widely understood idioms like global static configuration and adding async/await. But the macros I’m talking about were very simple, well-defined things that exist in other languages. They were just unfamiliar.
In any event, they’re ripped out now. But ultimately macros offer a lot more in theory than in practice.
And it shows. Some of the more impressive and powerful libraries have incredibly ergonomic and clear interfaces, because the language let’s you simply do more with it.
If you're not familiar with lisps in general, it might be hard to grok the differences between lisp-macros (as used in Clojure) and "normal" macros you see in other (non-lisp [sans Elixir I think]) languages.
But, if you are familiar already, and just wanna see examples of neat macros that makes the API nicer than what a function could provide, here are a few:
`spy` here doesn't just print what the `` form is returning, but the form itself too. You wouldn't be able to achieve this without macros, as the evaluation of the `` form would happen before it gets passed to `spy`, so the initial form is already gone. Instead, a macro received the very code you pass into it, so you can print it, inspect it, rewrite it or whatever.
Care to link some of those? Are they macros as in C-macros or macros as in Lisp-macros?
Macros in C-like languages (like JavaScript or TypeScript) tends to be relatively basic text substitution macros, while in lisp they are part of the core language, and you construct macros just like you construct normal code.
> while in lisp they are part of the core language
The power of the typescript toolchain is that a macro framework like ts-macros can be a package and doesnt have to be part of the core language.
If 20% of users want to be able to do something in a Lisp that the built-in macro system doesn't support, they either can try to get the change into the core language, or live without it (or fork it). If it changes, it'll change for everyone using that lisp.
But in Typescript, you don't have this restriction, so modifying the language for your own need, becomes a lot easier. Lots of work on Typescript and Javascript is simply done in packages, as it's possible and doesn't impact the core of the language, which everyone shares.
> The power of the typescript toolchain is that a macro framework like ts-macros can be a package and doesnt have to be part of the core language.
Lisp can do the same, but macros are so central, that everyone uses it including the core of the language itself and anything written on top. It's not optional, since syntactic meta-programming is one of the core features of Lisp.
That's strange. Being able to professionally work in Clojure for the last ~6 years or so is enough validation for me that Clojure is the right choice (for me).
Does my comment came across like that because I point out benefits from using Clojure, or what makes you say that?
As much as I respect Rich Hickey, it's hard to say anything positive about this. It has basically nothing to do with open source. It's entirely specific to how he chooses to run his own projects.
Open source is not a gift in the sense that you "get what they give you". You are entitled to the source code. You are entitled to modify the code. You are entitled to distribute your modifications.
Are you entitled to be part of the development process and to state your opinions about how things are going? Yes...if those are the rules of the project. The thing is, that has nothing to do with open source, it's always project-specific, so the full post largely doesn't make any sense as a comment on open source.
> The thing is, that has nothing to do with open source, it's always project-specific, so the full post largely doesn't make any sense as a comment on open source.
That's how I read this article. He argues that it's a misconception that "open source" implies the entitlements that he rejects. There may be projects which offer such entitlements (though it's unlikely phrased like that), but other projects don't, and nobody should assume they are entitled to anything just because of the "open source" label -- beyond the rights guaranteed by the chosen license.
He argues for freedom. The programmers freedom to ignore anything beyond the license, and the users freedom to go choose a different project if they don't like the choices of some project. That's also what you are saying.
I don't agree. Two sentences in particular drive me crazy:
> As a user of something open source you are not thereby entitled to anything at all. You are not entitled to contribute.
The first sentence is wrong according to any standard definition of open source. The second is specific to the project. It may or may not be true. He's making strong statements about how we should view open source rather than his project:
> The time to re-examine preconceptions about open source is right now. Morale erosion amongst creators is a real thing.
That's a statement about open source, and it's not filler that he threw in without much thought. It's at the core of his argument.
I think the context of Clojure as a project and a community needs to be taken into account when reading Hickey's "you are not entitled to anything" piece.
Clojure as a community is _VERY_ welcoming, it has a healthy level of discussion, a wide variety of users, and many innovative projects. I was surprised when I first read that gist in 2018, but I've come to believe it's a reaction to some people who perhaps had made demands or public/private gripes about Clojure in a way that rubbed Hickey the wrong way.
He perhaps could have communicated his sentiments differently. It seems a bit "scorched earth" to me. Admittedly, he doesn't say exactly who/what he's reacting to, so maybe it's justified.
But IMHO, for every raging a-hole who need to be told to slow their roll, there are probably a few earnest, well-meaning folks who will think twice about reaching out and contributing with valuable ideas, for fear of crossing the "you-are-not-entitled-to-anything" line.
Disclaimer: I think both Clojure and Elm are good technologies and I understand most of the trade-offs they've made. I wouldn't mind using either for a project or two in the future.
Some important context for me, when I read this gist, was that Evan Czaplicki had just written a post and done a talk that basically amounted to "People should stop being mean to open source maintainers".
The parallels between Clojure and Elm (which Czaplicki created) are actually a fair few; both are fringe, opinionated languages which brought some exciting new (in some sense of the word) tech to the forefront (FRP for Elm, persistent data structures for Clojure, etc.) and both languages were hosted in an environment that afforded very few niceties when they were created (both creators probably heard "You saved me from X!" a lot).
I think the most important similarity between the two languages is that they both have ended up with communities that feel like cults of personality.
The overwhelming feeling if you come into Elm as an outsider is that everyone literally feels like Evan Czaplicki is absolutely right about everything and everything he says will be taken as universal truth and probably even interpreted much more harshly than he meant it (if what he's saying is a comment on another technology, for example).
In Clojure this cult-like feeling is less obvious in many ways, but shines through in that people will literally just quote Rich Hickey talks as if they were the bible and also expect these quotes (which usually aren't very good arguments in themselves) to actually be considered legitimate arguments. Sometimes this will spill out into the broader community and it becomes obvious how little the followers have thought about the arguments involved, since they now have to substantiate something that in the Clojure community is just considered a given because of shared context and blind acceptance ("We can just regurgitate the quote and it's an argument against something").
I would argue that the problem that Rich Hickey and Evan Czaplicki have are caused by this same isolation in a community that seems to massively overvalue their opinion and reinforce it blindly at every turn. If all you hear is "Yes!" all the time the opinions of people with legitimate gripes are going to seem much more harsh and if you're unlucky some of them might actually turn out more harsh because of the dissonance between how normal people act vs. how people who bought into the cult act.
P.S.: If you're seeing parallels between the Elixir community and the above you're not alone. It's very hard to have discussions in that community without running into the same kinds of believers (usually with very limited real world experience).
Therefore it's correct to say that being a user of something opensourse doesn't give you a right to contribute.
Otherwise it's like claiming that it’s wrong to say that "as a US citizen you're not entitled to use the Air Force One" because the president is a US citizen and has the right to use it.
I think it depends on whether "contribute" refers to a specific official repository managed by a specific project, or to the general problem meant to be solved by the codebase. Open source doesn't give the right to contribute to a specific repo, but it does give the right to fork a project. That fork is a contribution to the general problem.
> Edit: Notably it seems some commenters here confuse the idea that FLOSS will allow for forking but open source does not necessarily do so.
This is not a confusion on their part, but on yours. "open source" is defined as it is deliberately, in response to organizations trying to confuse their users about the terms of the software they've offered. What you see today is the outcomes of years of debate from decades ago, and trying to have it mean something different would require a similar debate to change well-settled terms.
If you want to talk about software where the source is available but may not be forked or redistributed, use terms like "source available" (which has its own Wikipedia article https://en.wikipedia.org/wiki/Source-available_software, showing that this isn't just my term or those of the other commenters here).
It is license specific, and if forking is not allowed then it is not an open source license [0]. I consider "Open source" and "FLOSS" as equivalent terms, since "open source" as a term was proposed as an equivalent term to avoid negative connotations of "free" as low quality or not worth paying for[1].
The L for “libre” in FLOSS may be to avoid negative connotations of "free" as low quality or not worth paying for.
The link you referenced are talking about an entirely different conflict, and it is very much not meant to be equivalent. Open Source was all about distancing from the political ideas associated with free software and the GNU project.
> Edit: Notably it seems some commenters here confuse the idea that FLOSS will allow for forking but open source does not necessarily do so.
this depends on your definition if open source. OSI's definition of open source states
"""
3. Derived Works
The license must allow modifications and derived works, and must allow them to be distributed under the same terms as the license of the original software.
"""
https://opensource.org/osd
Which allows forking. I don't think that any definition of open source not allowing that have a wide spread support.
Aside from the software license there is the question on trademark licensing. Some projects like Mozilla are quite strict on that, that however doesn't prevent forking Firefox, but just requires using a different name (like IceWeasle)
It does not necessarily do so if you make up your own thing and label it open source rather than using the standard, intelligible, non-deceptive definition. For example, if you name your dog "Open Source," that doesn't even give me the right to pet it.
But I don't think anybody is interested in talking about your dog.
I was giving my definition, which I consider the "industry standard" which is the one by OSI (while I have some issues with the organisation that definition is useful)
It depends on your definition of contribute. You aren't entitled to have your PR merged to the main project, but you are entitled to fork the project and make your changes over there. The first is contributing directly to the project, while the second is contributing to open source at large. I believe the author was referring to project specific contributions.
I think you have a wrong definition of entitled. You're never entitled to make contributions to any open source project. Any such project may or may not give you that right, but it's not something you're entitled, it's explicitly given to you.
I agree with this but I don't really blame people for assuming they have the right to contribute code anyway. There are developers out there who directly challenge others to contribute when they say things like "patches welcome" in response to feature requests or bug reports. Now people aren't entitled to contribute? Makes no sense to me to be honest.
Only thing worse than submitting a patch and being ignored is watching someone else commit the feature or fix in spite of the contribution.
> having a right to certain benefits or privileges
The right to contribute is a property of the project, not a property of open source, which has nothing to say on how projects are run. And for the record, I don't agree with his project management style.
> not a property of open source, which has nothing to say on how projects are run
If open source does not require that a project accept external contributions, then Hickey is right to say that you are not entitled to contribute just by virtue of being open source.
You're right that this is a more to do with the project in question than whether it's open source, but open source does compel projects to do other things. So it is not weird for Rich to clarify for users of his open source project that its being open source doesn't compel that project to accept external contributions, in the way that being open source compels them to distribute the software.
> ” The thing is, that has nothing to do with open source, it's always project-specific, so the full post largely doesn't make any sense as a comment on open source.”
I think that’s exactly the point he’s making. To phrase it another way, open source is orthogonal to the relationship between the stewards and the community.
> Are you entitled to be part of the development process and to state your opinions about how things are going? Yes...if those are the rules of the project.
You can always fork the project if you disagree with how it's being maintained (or not maintained, as is the case often enough). Right to Fork is integral to FLOSS.
OSS part of FLOSS stands for open source software. It is an integral part of free software as defined by the FSF, and to open source as defined by the OSI. Any other usages of the term(s) is either ill-informed or malicious in an attempt to make it more ambiguous.
He is clearly responding to people who have a misunderstanding of what open source is, so you cannot blame him for correcting the wrong understanding as if he is the one who defined open source to include these additional expectations that go beyond the license. He is merely pointing out how the way he runs his project is also in accordance with the license.
Maybe it would be better to understand the context of events that lead to the letter than argue with generic platitudinal responses about what open source is that are totally debatable, e.g., you are only entitled to whatever source code they give you and nothing more, and you are only entitled to distribute your modifications if the open source license allows it, redistribution is not automatically a feature of all open source.
It’s certainly true that there are users out there who expect unreasonable things to happen just because they say so, right? Have you been on the receiving end of user demands? I certainly have. Your reaction might be different if you knew that part of the story. This is why your reaction sounds like it might land under Hickey’s qualification “If you don't recognize yourself in the message above, it's not for/about you!” He’s speaking to the unreasonable people who have demanded things of him and his project, not the reasonable ones who already understand what open source is or is not, right?
Rich is making the same argument as you are: a project being open source does not determine whether users are entitled to be part of the development process for that project.
>Are you entitled to be part of the development process and to state your opinions about how things are going? Yes...if those are the rules of the project.
Open source isn't a a code of conduct. It is a licensed though. The subject and title is not about random projects, it's about clojure and open source.
I would phrase it that open source is just about the license of code, not about anything else, and definitely not about how changes are applied to such code.
Usually, it just practically means that you are allowed to make changes and redistribute them, but without giving any guarantees on how these changes are going to be made available to others.
> 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.
Everyone has their own frame of reference and their own opinion on what is right or wrong in a particular situation. There could also be a singular objective hierarchy of morality or righteousness - but each person is going to have to come to their own conclusion about if that exists or not.
I think the philosophy of engagement they outline there is internally consistent, but I don't think it supports where they go next:
> If you think Cognitect is not doing anything for the community, or is not listening to the community, you are simply wrong.
It's consistent to say that you do things for your own reasons and other people are not entitled to any engagement w/r/t their opinions on your work - but then also you are not entitled to anyone else agreeing to your opinions either. You can have all the opinions you want about your own work - but you're not entitled to anyone agreeing with them. The idea that doing the work should mean something for you is, after all, just another opinion.
Alternatively, you could proceed from an ethic of building a shared understanding of creative community. Then you get to say things like "you are wrong if you don't think we are helping" - because you have a definition of community that you're following and the work you are doing is structured to support that definition. But then complaints do have value and standing, because you're promoting a kind of social contract. Not all complaints have standing ofc - but certainly some will!
Are you able to shed some light on where the entitlement is coming from?
Asking as someone who has honestly never held such assumptions, I remember quite clearly my initial instinct towards various FOSS projects as "their castle their rules", I'm kinda puzzled why anyone would think otherwise... but this is a long time ago in internet years.
Perhaps this is a hot take, but Rich's headline is wrong. His argument hinges on the idea that software chooses to be open source out of altruism: someone created something of value, and rather than requiring payment they gifted it to the world. But if you have ever been at an organization that makes open source software, there is always a calculation that at least suggests that the company is better served by using an open source license. Part of that calculation is people filing bug reports, proposing improvements, and in general being satisfied with the library. Some requests are too niche, and some arguments too baseless, but if the people using open source don't participate at all we often say that something isn't really open source at all (see Apple's "Public Source"). When that happens, people tend to make forks, build competing libraries, or give up and move on.
Open Source isn't all about you, but it is a little bit about you.
> but if the people using open source don't participate at all we often say that something isn't really open source at all
i cannot say who the 'we' is, but i suspect in some circles this may hold true. i do challenge that this is a reasonably held belief because it is an expansion of the historical responsibilities generally held towards those who would wish to open up their source for others. it may even suppress how much code is openly shared (since most engineers don't enjoy being community managers)
It's an old debate, and I'm not familiar with the current usage.
Stallman explains: "The two terms describe almost the same category of software, but they stand for views based on fundamentally different values. Open source is a development methodology; free software is a social movement."
Clojure is Open Source by this definition, since it is developed by a collective group, as opposed to a permissibly licensed but static artifact. People are welcome to run their projects however they like, but the entitlement comes from the philosophy that Open Source is more than a contract, and is better when there is participation. Labels matter because they set expectations – Apple does not call their Public Source "Open Source", and people don't complain because they understand the difference.
Agreed that the labels matter and some of them are slippery. Some are made slippery with cavalier intent by influential people, either by redefining or hitching their movement's cart to a better known thing. Stallman and others want to expand open source to be more than what the license says. I am proud of the achievements of that movement, but I regret that muddying labels leads to dilution and confusion.
Apple recognizes the state of this confusion and perhaps wisely uses a different definition to avoid conflict. The Clojure maintainers do not, because they interpret Open Source by its original definition. Just because a collective group is involved does not mean its maintainers are compelled to the responsibilities conveyed by Stallman et al's extension of what open source is.
I am inclined to think this a ‘generational’ issue. For those individuals that were using open source before the explosion of the modern internet, open source software was something we could seek out to then use for our own ends. Also, the people who wrote that software were ‘publishing’ it just to get it out there for anyone to use if those people found it useful.
Conversely, people who started using open source after the internet exploded, and I think particularly, once being an open source maintainer was seen as an achievement and goal, the attitude changed. Individual users of the software were building things depending on the OSS and felt that their use of the OSS code implied a contract for continued development of that dependency. This feeling is made worse by fiscally gigantic corporations pushing ‘oss’ products and those corporations acting like their continuing to support their product is analogous to a solo dev putting a vim plugin on github. The reality of wide spread large ‘oss’ products and the implied (and often maliciously relied upon) personal obligations of producing OSS have led to the current state. That state being users of some OSS assuming that their usage of the software means the author owes them some obligation by virtue of their need.
This whole issue is made worse by large organizations getting social credit and positive marketing by releasing ‘oss’ products. This leads to conflation of individuals releasing code to benefit the commons vs. organizations doing so to capture markets, gain publicity, etc.
People (me included) think that publishing and maintaining software is an implicit guarantee of (or attempt at) some level of proper behavior. When the software doesn't work as it should, people feel that that guarantee has been violated.
Many contribute fixes and actively improve the software, but many post entitled comments.
7. Disclaimer of Warranty. Unless required by applicable law or agreed to in writing, Licensor provides the Work (and each Contributor provides its Contributions) on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied, including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE. You are solely responsible for determining the appropriateness of using or redistributing the Work and assume any risks associated with Your exercise of permissions under this License
I agree, the non-stop one-sided accusations of entitlement didn't seem very productive to me. I wonder if some day someone will write a post about things maintainers aren't entitled to. I can think of several things.
This is in no way exclusive to software. It's people in general. Dealing with people is extremely difficult. At least software developers aren't likely to get sued over these complaints.
Yes, the word "entitlement" is mainly used in response to widely acceptable behaviors, and is almost always a passive-aggressive escalation.
I may not be entitled to be listened to when I speak, but it's still reasonable for me to speak with the expectation that I will be listened to. If I do speak, it's not an aggressive claim that I'm entitled to speak and you must listen.
To some extend of being a human you are. Are you entitled to expect things to go exactly your way? No. Are you entitled to get what you want without trade? No.
However, the whole claim of "we are going to do everything we want" and you're going to give us appreciation and some kind of resources (admiration, money, time, commits) is just selfish.
Humans are social animals, what you create and put out is mention to be used by someone. It's not just wankery that is there for people to not get something of it.
No one is entitled to much in life. But people expect many things which they aren't entitled to. This is normal, and does not mean there's something functionally wrong with people that expect certain things.
I expect my neighbor to not flip me off every morning. Am I entitled to it? No, not really. Being an asshole is not illegal. But I would probably still complain about it. Does that make me entitled?
What you need to do is manage expectations. Which... this is one way to do it.
Expectations can be set by the license, most of which used for open source explicitly outline that the author is under no obligations.
There's quite a distance between your example and the behavior of most open source developers. Are you implying that those who don't respond to suggestions are flipping you off?
It's clearly arguing that we expect many things that we have no right to. Open source developers aren't bound by any expectations that we have of them, but we also have no duty or obligation not to have expectations.
My 2¢ is that some open source maintainers have severe boundary issues that are pretty natural for people to have. They need to be liked by everyone, which is probably why they decided to do OSS, because if you give people things for free, they like you.
People's expectations rise to the challenge and demand the maximum amount of free stuff, and the maintainer is pushed to their limits to satisfy them for little or no renumeration. But if they stop, people won't like them, and that sets off some useful animal heuristic where that possibility causes them to feel in actual danger (which they may project onto the project i.e. "the project is being endangered by entitled users asking for things.") The loss of what you think people love you for (giving away free shit) is a loss of identity and one's place in the world.
The reaction of the demanding users is just as natural. Remember: if you feed a stray dog, people don't naturally feel the dog is now obligated to you, they feel that you are now obligated to the dog.
You have to be modern, establish boundaries, and not place enough of yourself in the expectations of other people that they can destroy you with disappointment.
It might be better to move to proprietary or Free software. With Free software, you're establishing something and granting it to the public (not becoming something), and you can walk into and out of it with no feeling of guilt or of being taken advantage of. No one else will get rich off your work, and if your work helps people it will live forever. With proprietary software, you're dealing with safe, formalized purchase and support relationships. It's this OSS shit that seems to drive everyone crazy.
You speculate too far. One may wish to share their work for many motivations aside from needing to be liked. A gift is best given with no expectation of reciprocation.
Open source has a definition, but some movements have saddled it with additional expectations. Disappointment can arise from malformed expectations. When that happens there are a few options. One can avoid disappointment by seeking new labels when existing ones are compromised. Or, one may recognize this subversion as a power play and challenge it. The latter path sometimes doesn't end well.
Whichever path is taken, I agree that the objective should be in establishing boundaries. The author of the article achieved that, at some cost.
There are some duties that apply to people that are open sourcing stuff:
* Don't lie about what it does.
* Don't hack people by smuggling some nasty code into minor version updates.
* Don't leave people vulnerable to third party exposure by not taking care of your private keys.
I am an Open Source dev myself, having about 300 modules on npm. I use it as reputation credit for actually getting jobs that pay good money.
If you are an Open Source dev, you are a "Code Influencer". You have to be straight about what you do. It is the same for normal influencers when they have to declare any paid promotion stuff.
Sorry but there are no extra duties implied by open source other than what's in the licence. Licences usually explicitly say that there is no support and no implied duties other than those guaranteed by law.
Open source/free software existed long before nebulous[1] terms like "influencer" came into fashion.
All it means is that you get the source code and some limited rights to modify, distribute and run the code. The rest is on you.
If you don't like the licence, don't use the software.
If you don't trust the author or group behind it, don't use the software.
If you don't think the project is well run or not, don't use the software.
If you don't like the politics of the people involved, don't use the software.
If the website "smells funny", don't use the software.
If you can't tell if the software is safe or not... you guessed it, don't use the software.
If you drink from puddles then it's up to you to decide if the water is clean or not.
1. i.e. there is no definition in law to what this means.
You're describing things that are legal requirements and legal duties. The parent is arguing that there is a moral requirement and a moral duty to uphold.
Those "moral requirements & duties" usually go into a "Code of Conduct" or "Contributor Guidelines" instead of in the license of the project, as they are separate from the distribution, usage and modification of the code.
And rightly so. The community seems to constantly mix "open source" the distribution model with the "open/community" development model that some projects adhere to.
We would all be better off by being more precise with what words we use to describe all of these things, and what our expectations are. Just like what Hickey did here.
I am referring to moral duties that exist independent of the project they are in. An individual project's Code of Conduct may recognize pre-existing moral requirements, and may apply additional moral goals that the project upholds, but it can neither supplant nor disclaim moral requirements that pre-date it. If an update to a project adds a keylogger and exfiltrates your login information, that project has failed in its moral duty, even if not explicitly stated in the project's CoC.
Well, one of the problems is that there are groups (though few) who want the social sheen of having an "open development process" while not actually accepting input. The fact that the source is published is deliberately conflated with the idea that the community is open, for marketing purposes.
"Common decency", much like "common sense", is just a projection of one's own values on to others.
I dislike telemetry and ad tracking and I avoid software that includes them whenever possible. I think they're against common decency but I know that others disagree and think both are perfectly acceptable.
We'd all like to believe that we share a definition of what "common decency" is but sadly we don't. It's why we resort to the law to settle disputes and why we need legal professionals to interpret that law.
What you're describing, misleading users or publishing malware, these are not things controlled by some notion of common decency or some personal moral code but either by statutory rights or criminal laws. e.g. in the UK with have the Computer Misuse Act to stop people adding things like time locks to software.
That's completely different to whether the source to an application is available and whether you can distribute modified versions of that source.
> That's completely different to whether the source to an application is available and whether you can distribute modified versions of that source.
That’s fair. My point was that the obligations of open source developers/maintainers do not begin and end with the explicit terms of the license, which is true. There are laws (and norms, though you don’t seem to acknowledge those as legitimate) that publishers of software are obligated to comply with.
So everyone should reject all proprietary software outright (at least for internet-connected devices) and become fluent in programming languages to determine good from evil?
> There are some duties that apply to people that are open sourcing stuff:
No, zero duties. The express purpose of Open Source is that I can release code for free to world, and it's your responsibility to figure out if it's what you need. Adding some arbitrary "duties" that people must fulfill to release open source, is something else, and should not be called just "Open Source" as that already has a definition.
If you get hit by any of those points you list, then you're the one responsible for that.
> If you are an Open Source dev, you are a "Code Influencer".
That's mixing up terms. Open Source developers are developers who release Open Source code, that's it. People who try to "influence" the ecosystem one way or another, could be called "code influencers" I guess, but please don't mix them together. One doesn't imply the other.
Nope, you never have zero duties, as much as you would like to be a jerk to people. Just like putting salmonella in your free cookies will get the police to show up at your door real quick, releasing open source code with malicious behavior, or lying about what you’re doing, or just straight up being a rude person is not really acceptable, open source maintainer or not. There are appropriate consequences for all of these, and not all of them involve the legal system.
Purposefully poising people without disclosing that, is illegal. Yes.
Purposefully infecting computers with viruses without disclosing that, is probably illegal too. Yes.
Publishing code that on purpose infects computers with virus but disclosing that, is probably not illegal.
Publishing code without any disclosures at all, which happens to infect people, is probably not illegal either.
You don't have to download random code from GitHub and run it. No one is forcing you to. And if you do so, you're responsible for your own actions.
Lying about what you're doing or being rude is shitty, and the ecosystem should not support that, I agree with that. But throwing in a MIT license together with some code you publish, doesn't simply that you won't lie or that you won't be rude. It just says that you can use that code if you want to.
What you're looking for if you're looking for promises of not being lied to, is something closer to a Code of Conduct or Contributing Guidelines. It's outside the scope of (most) licenses.
Right, there's levels of consequences here. You're very focused on what's illegal. Some of the things I mentioned are illegal and you would probably be sued/go to jail for them. Some probably aren't illegal or may even be explicitly legal (NO WARRANTY, etc.) but there are still consequences to doing it. You'll often only get the chance to get people to try your published code that happens to infect them once, and after that they will not only avoid your software but also get people to do the same. They may even be upset that your software did this, because despite there being no legal agreement in place between you and the person that downloaded your software to prevent this, they do have a social expectation that you're not being negligent, or misrepresenting your code. Nothing stops them from calling you a jerk.
I agree but you’ve just explained nicely why this duty has nothing to do with open source software. The duties you’re talking about are universal. Are there any special duties open source devs have that other people don’t have?
>> * Don't lie about what it does.
>> * Don't hack people by smuggling some nasty code into minor version updates.
>> * Don't leave people vulnerable to third party exposure by not taking care of your private keys.
>
> If you get hit by any of those points you list, then you're the one responsible for that.
If someone on the street hands you a free sample, say a candy bar, is it then your responsibility to check that the candy bar:
1. contains no razor blades (malicious behavior), and
2. contains no peanuts because of your allergy even though the packaging says it doesn't (lying about what it is)?
Obviously not, anyone handing those out violating those assumptions is an asshole and in most jurisdictions a criminal. It is not the responsibility of the acceptor to check these things, our society expects (and enforces through the law) that people are honest and non-malicious. Even if the sample is free.
The exact same applies to source code you distribute. It would not be reasonable to analyze every free candy bar for hidden razor blades by meticulously taking it apart, nor do a spectral analysis for peanut traces in exactly the same way it is not reasonable for people to verify every line of code.
>> It is not the responsibility of the acceptor to check these things, our society expects (and enforces through the law) that people are honest and non-malicious. Even if the sample is free.
>> The exact same applies to source code you distribute. It would not be reasonable to analyze every free candy bar for hidden razor blades by meticulously taking it apart, nor do a spectral analysis for peanut traces in exactly the same way it is not reasonable for people to verify every line of code.
That is not what the licenses say.
Most FLOSS licenses have a clause like this:
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.
If the author explicitly disclaims all responsibilty about the released software, then all responsibilty falls on the user.
I couldn't care less about the definition of what an "influencer" is or not.
What we're talking about here is releasing code as FOSS. Just because I add a MIT license to code I publish publicly, doesn't mean I want to be some "influencer" or whatever. It just implies (rather explicitly) exactly what it says in the license text, nothing more, nothing less.
I'd say that your rules apply to everyone whether or not they are part of an open source community.
Being a closed source dev doesn't make malware morally acceptable. Lying is a complicated thing as everyone does it, but no matter the context, you can't be surprised if you face social consequences for deceiving people. And allowing people to use your stuff for wrongdoing is also going to affect your reputation, in the same way that someone using your Facebook account for bad shit is going to come back to you.
A more interesting discussion would be on the relationship between a volunteer organization and its volunteers, as this post is probably in response to a recognized community contributor.
Those are all nice things to do when managing a project but they are definitely not obligations. Some of us open source developers don't even work as professional software developers.
I for one reserve the right to simply abandon a project once I decide it's served its purpose. I often start projects to make tools for my own personal use, to learn something by trying to reinvent a better wheel or just to prove to myself that I'm not insane for imagining different ways to do things. Fear of inadvertently creating responsibility for myself, such as responsibility to polish, maintain or even finish projects, has led me to not actually publish lots of software I've written.
One such project actually made it to HN once. It's really nice when other people see your project, I'm happy even with criticism because it means I can learn something. However, I really don't want this to turn into an unpaid duty. I try to do things properly when I'm programming but at the same time I have increasingly limited free time and attention.
For example, I wrote a user space driver for my laptop's keyboard LEDs:
I just wanted to turn them off because they default to bright blue lights. Then I thought it'd be interesting to add some application-specific color schemes.
While reverse engineering it, I discovered some insane functionality. The Windows driver would intercept all keystrokes and send signals to the keyboard to light up the keys when they're pressed. Why not do it in hardware? I started documenting those features but it was just so insane I decided it was better to just stop. I really don't want to feel pressured to finish that, especially since I'm not going to use it.
Then it turned out I actually had users, and one person created an issue asking for help with the somewhat cryptic user interface I came up with. I realized in horror the issue was created months ago and I didn't even see it. I tried to help as much as I could but still.
> I realized in horror the issue was created months ago and I didn't even see it.
I even had one issue opened for three years before I found my self with some extra time for the project. Was quite surprised, but delighted, when the submitter responded with a thank you, and “worth the wait” just minutes after resolving it.
I guess what I’m saying is, don’t let the pressure take you down to much. Most people are probably both patient and grateful.
There are open source authors who worked hard at, and have succeeded in popularizing their libraries. They create slick marketing style webpages for their docs, often to the detriment of it's actual usability, but certainly the eye-candy helps adoption. And they seem to spend more time in this endeavour, the popularization, of their lib, then making their docs more thorough and fixing the various issues that pop up with their lib. I have an issue with these open source authors. Because even if I personally disdain their work, and abstain from it in projects under my control, at every company I go to I either have to encounter it in use and deal with its flaws, or have to defend a codebase without it from someone joining the team and suggesting we use it. The open source authors obviously gain a benefit the more github stars their work acquire. So yeah... sorry I don't buy the 'they don't owe you nothin'. They worked and sweated to get their fucking code on my machine and then instead of fixing bugs they close issues flippantly, cherrypick examples of bad issues raised as if all issues raised were of similar calibre, and basically do a big dramatic 'le sigh' when actually confronted with the responsibility of fixing their fucking work. If this is how you feel don't beat on every door and bang the drums and say your lib is God's solution incarnate come to earth to silver bullet the problem. I should be seeking out your lib, your lib should not be seeking out my codebase.
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.
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.
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.
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).
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’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.
The thing is, yes the people who run a project can do what they like, but everyone else remains entitled to their opinion. In the best case scenario, people who are profoundly unhappy can walk, and indeed that’s what’s happened to Clojure. In the worst case, the investment in a platform is so large that people can’t leave. Those people are likely to be pretty vocal if your decisions negatively affect them.
I dislike this kind of semantic bickering. Yes, technically "open source" once meant only the distribution model of source availability. A lot of time passed since, and now "open source" means something else - a certain social phenomenon with its community, rules, culture and mores. Lamenting that people have grown to expect this is pointless.
Yes, some people can be over-entitled towards open source - and it's the right thing to push back against them and remind them they wants aren't the law of the universe. But it's also wrong that "open source" is just a licensing mechanism. It's a culture, and how people behave forms this culture. That doesn't create entitlement, but it creates certain expectations. No one is obliged to deliver on those expectations - especially if they are exaggerated - but I don't think it makes sense to deny they exist, and usually accounting for at least some of them leads to better results than ignoring them.
So what I notice is that there seems to be a spectrum between feature-conservative and feature-enthusiast open-source projects.
RH doesn't name any names but there seem to be more feature-enthusiast projects out there. I wonder if someone could name an example and see the pros and cons of the two approaches.
I guess one good example (that was mentioned just yesterday here on HN) would be Flask vs FastAPI: https://news.ycombinator.com/item?id=31953470 - "There are no open issues or pull requests on Flask "
Quick count finds that FastAPI has 48422 lines of code, while Flask has 9995. Flask just achieved "Zero standing issues/PRs" while FastAPI has 1.1K open issues and ~500 open PRs.
Large surface area/API quickly leads to be overwhelmed when you're trying to maintain it. Adding new features/fixing existing ones becomes harder as well.
Best bet to make sure something is maintainable over time is to add as little as possible to it, and if you really have to, make sure you're also removing something at the same time.
Otherwise you need a massive team just to be able to "survive" and not making things rot.
Someone run that tool on the Clojure codebase as well, and it really shows how well the Clojure codebase has been written, as most code that was initially written is still there and does what it needs, without having to be rewritten.
> So when I say in passing “if it doesn’t matter to Rich, it won’t get in”, it’s not a slight, it’s a statement of fact. People are limited, and must prioritize, your ticket will most likely be deprioritized unless it’s directly related to whatever Rich is currently working on.
> In addition make sure every assumption, every detail you’ve thought of, every possible side-effect of your code, is mentioned in the ticket. Because if you forget to mention something, Rich will most likely catch it, and hand the ticket back to you with a comment of “did you think about X”, that will add another few weeks into your dev time.
> Now begins the “personal opinion” section, what I’ve stated here are the facts as I’ve worked on Clojure and the core projects. I got tired of the constant back-and-forth. Never being able to talk to the decision maker directly aside through a 3rd party. Problems that could be solved via a 10 minute meeting blow up into months of back and forth discussions, and if any party gets busy and forgets to get back to the other about the ticket, that process just takes longer.
The TLDR of the post seems to have been that it takes to long for him to get in changes that he cares about, while he feels like the Core team is focusing on things that are not as important (implicitly at least).
On a happy note, it seems Baldridge is at least acknowledging his missteps with the whole situation with the whole "Thanks for everything Rich, and please don't take my current leave-of-absence from the community as anger. It was out of anger last week, but now I'm using it as a way to reflect" part.
I was around in the Clojure reddit when Rich's gist was published. It was centered around a really, really specific scenario:
A well-experienced community member had a strong following: wrote many libraries, articles, and even started contributing to core. Over time, they had more and more thoughts about how Clojure core should work and what the priorities should be. After some inciting incident, he used his reputation to start rallying his followers on social media against the maintainers and leadership to push for his way.
That's what sparked that post as Rich felt it was unacceptable to rally people against the maintainers and leadership because you did not get your way in a PR or discussion.
I can see where he's coming from as I wouldn't want open-source projects to be ran by the person who can drum up the biggest and meanest mob either. Personally, I wish it was handled with more tact on both sides but eh, no one is perfect.
Meh, I think this attitude misses the some of the fundamental social dynamics in the open source world: projects—at least the ones you've heard of—aren't just code, they're communities. People using, or even just talking about, a project are a part of the community. A small part, perhaps, but a part nonetheless. If a project wants to be "successful" in the sense of being popular or active, it needs to maintain a community which almost always includes the fringes outside the core contributors. People who are part of a community, however tangentially, will want something from it, or they're just going to leave—that isn't entitlement, that's just how people's attention works!
There's a reason that—"just fork it" rhetoric aside—forking an active project is often seen as an actively hostile social move: it's not about the code or the license, which allow forking by design, but rather about potentially splitting the community. And this also makes sense; if you've built something and want people to use it, having somebody else take their own version and convince people to switch isn't going to feel great! But there's an inherent contradiction between "trying to split the community by forking is hostile" and "the community is entitled to nothing": if you're getting some value from having a community, people in the community wanting input on the direction is not pure entitlement! Now, to be clear, this does not mean that every complaint or request on a maintainer's time is reasonable, and I've certainly seen many interactions that cross the line—but, ultimately, if you're a maintainer and care about having a community around your project, you become a steward of the community by definition. And for stewarding a community? The "you are not entitled to anything" attitude is fundamentally toxic and counterproductive.
Critically, none of this applies if you're just making an open source project for yourself. Do whatever you want! But then don't be surprised if somebody forks your efforts and gathers people around a "competing" effort. But you can't have your cake and eat it too; if you want a project that goes beyond just yourself, the community around the project starts to be something that matters.
If you want to build a real community around it there needs to be give and take, you can't just throw the stuff over the wall for the hoi polloi. That might not be suitable for a small project you are content with doing yourself or you might want to set yourself up as the unquestioned god-emperor, who allows others to work for your greater glory but who will not allow any competing vision. I don't like the latter kind of project at all.
Open source is about you, or could be about you, if you find the right kind of open source community.
What open source means and what different people choose to use it for are different things. Of course as a maintainer you may get more out of it if you put effort in for building a community, which then can help you improve the project, contribute, etc. But that's extra effort, and nobody should assume that everybody commits to that extra effort just because they release source code under a FOSS license.
A huge part of open source is open community, open to feedback, open to suggestions, feature requests and contributions. Obviously there's no entitlement but it's one of the few actual benefits of open sourcing.
Edit: I know about "open source but not open contribution" thing which is quite rare (esbuild for one). I don't think that's a good idea for the health of the project.
I know not everyone has the mental strength to run and moderate a community but in the software world, a community is akin to being a celebrity. People follow you, wait on you, listen to you, value you, troll you, throw insults at you, shout at you, and show attitude to you when you don't owe them anything. The best part is that someone somewhere knows you. Fame is a huge motivator.
If all of the open source projects had huge communities and no funding, there'd be more actively maintained projects than there are now with very few communities. I might even say that a few dollars here and there might not even make a huge difference compared to a few people making issues, taking interest and contributing.
Now I know not everyone is like that or should be like that. I am not generalizing here but come on. When you put your effort out there, it is quite reasonable to expect some form of compensation or appreciation.
If all the open source projects just put the code out there and called it a day, that'd be a huge disservice to the world. Open source is the birthing ground for a lot of software engineers and all their learning is due to them being a part of a community and contributing.
And as to be expected the bad comes with the good. That's alright. If you take the decision to run a community, don't worry about a few bad apples here and there. It's a part of the deal.
The benefits of being open community far outweigh the cons. It's no obligation but it sure is a good thing.
while i agree that open contribution software is a genuine good for this world for the reasons you enumerate, it is a _subset_ of open source software. OSS by itself does not imply that the author wishes to manage a community around the code they are freely giving. this common conflation causes authors to abandon or suppress ever releasing their source openly.
A lot of people follow the mentality that because something is free that it means no criticism or improvement or expectation is valid.
That is disingenuous because there are competitive forces just as much as a payment based system. Most things we like about open source are a direct result of that.
People compete for personal clout, for community clout, future employment status, future business partnerships
I'd still like the ability on GitHub to easily lock down PRs and issues to a trusted set of a dozen or two collaborators.
I really don't like this idea that because I open source some code that I'm working on for free that I become the help desk and abuse sink for anyone who can figure out how to register on GitHub.
There's a tax every time you need to read someone's pleading showerthought and close it because you don't have the time or don't care to do it. You still have to read it all, you still get annoyed by it all. Unless you're a total emotional robot none of it is actually free.
It is also interesting that I'll get downvoted and criticized for wanting to run my own project this way. As the first sentence of the linked note puts it:
> 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.
Lots of people out there seem to want to force me to collaborate with the world, for my own good, not just open my source code up for use. All I want to do is limit collaboration on my own solo free-as-in-beer project.
As someone who started and ran a very successful open source project, I feel his pain. You get a large following of adopters, some of whom feel entitled to demand features or priority for bug fixes even though they aren't contributing anything to the project. If they don't get what they want, they start bad-mouthing you in order to bring more pressure. After about 6 months of observing this, I finally had a good discussion with my brilliant Principal Architect, who helped me respond as follows...
If you would like a new feature or bug fix, you have the following options;
1 - Improve the code yourself.
2 - Pay someone to improve the code.
3 - Ask nicely, and wait patiently. Or,
4 - Openly criticize the project leads.
If it were me, I wouldn't choose option 4. But that's just me.
Once I posted this to the main forum thread where people discussed the project, most of the participants rallied to support me, and peer pressured in the discussion threads helped keep open source entitlement to a minimum.
For context, this rant was inspired by someone who complained that "1. Improve the code yourself" was prohibitively slow and even if you did solve the problem there could be a months/years-long turnaround only for it to be declined:
I don't think they're wrong that it's not a great way to work for the contributor and I can see why they'd want to write this gist in frustration. They're obviously being mostly fair to the people involved, but think that the process is just tedious and bad for contributors.
So I think you're off base; you're not in fact talking about the same issue here and Hickey is addressing real contributors who are trying to improve the code.
Strongly agree but it won't impact users being users.
Paying users have made an investment and have something to lose. Users of free at cost tools and products view that have nothing to lose so some act very badly. Unfortunately this won't go away with a rant, but support for fellow devs against bad users is always worth acknowledging.
Maybe it's the point, but reading this, I would never even consider submitting a patch or a bugfix after that tantrum. Even though most of his points are true, that "leadership" style screams stay away.
You might change your tune after creating a large project like Clojure. The amount of bullshit communications Rich receives must be off the charts. As a group, I don't think programmers are the best at considering the feelings of others.
It's a bit annoying to go through that post without knowing the context of why he's so pissed... Honestly, Open Source is a great source of frustration exactly because they're managed by benevolent dictators that are more often the latter while forgetting the former.
Yeah sure that's their piece of code and you're free to fork if you don't like it, but why open sourcing your project in the first place if it is not to have a benevolent ear to potential contributors, in other terms to create a community? An Open Source project without the community is just futile.
> why open sourcing your project in the first place if it is not to have a benevolent ear to potential contributors, in other terms to create a community?
one reason: providing code that others may learn or benefit from even while you recognize that you won't have time to manage a community.
I definitely understand there are reasons outside of that, but you should be ready (and happy) for a community to build up on your release of interesting Open Source software.
it's quite a thrill! until the months fly by and you get a particular kind of tone on an issue opened on your repository for a thing you can't devote time to anymore. and that burn can scar.
Sorry, but no. Publishing open source software incurs a self-imposed obligation to the community to support it--and that means most of what Mr. Hickey claims aren't entitlements--or else explicitly abdicate responsibility (and thus control) of it.
There are of course no legal obligations (unless the specific license of the project specifies otherwise). But this isn't about that. It's about the expectations and norms that develop in a community.
Ya that was my feeling too. I love most aspects of Clojure and especially ClojureScript, but his post feels like projection to me. When someone calls someone entitled, it just means that they feel a lack of entitlement in their own life, probably because they are being taken for granted.
To truly transcend in programming or any other discipline, we must first conquer ourselves. Which might mean letting go of expectation, especially from others. If bug and feature requests are piling up to the point that they distract from the work, then maybe their piling up has value. Being mindful of that doesn't mean solving it. It could be more about delegation, or communication, or setting boundaries, or any number of things.
I sympathize with him tremendously though. I don't even have a public body of work to showcase, or a way that leads to fame or fortune. Yet I still feel tremendous pressure to perform some days. His post doesn't read too terribly in the face of that kind of pressure.
I'm not going to impose stupid distribution terms on my users or force them to copy files around. It's dumb. If I'm making the code available to the public then just let the public have it. This post looks like it was written by an attorney not someone that cares about sharing ideas open and freely.
> it was written by an attorney not someone that cares about sharing ideas open and freely
Of course it was written by attorneys. Do you know how FSF, DFSG and OSD even began? They found a legal solution to the problem of sharing code while guaranteeing certain rights for the user who use the code! The open source licenses are written by attorneys too.
You are free to distribute under whatever terms you want but your code does not become open source just because it is shared with the public. Some countries do not even recognise "public domain". In such countries it becomes necessary to attach a valid open source license to your code. That's why the various open source licenses are drafted by attorneys to ensure they can provide appropriate rights to the user of the code.
> Far fewer than 1% of Clojure users are our consulting or product customers, and thus contributing to our livelihood.
Ouch, he just said 99% of the community is worthless to him.
Fame requires fans. If every non-paying user stopped using Closure tomorrow, that would be the beginning of the end for Closure, including the paying 1%.
open source is not just one thing. I think of it like a bunch of tribes loosely operating in amongst each other with some shared tenets (followed as necessary) and their internal own cultures.
But that's the same as any organization. In normal business, you're meant to follow the main tenet of "maximize profit", "treat customers well". Businesses follow those tenets as they see fit. There's no reason for every open source project to be cookie cutter.
I'd certainly be interested in hearing the story behind that.
Personally, I have no use for Clojure, myself, and, thus, no opinions on the project, or its participants; other than to sincerely wish them well, and success in their endeavors.
Because Clojure (as a specific project) is not something that I use, my opinion of the tool has no bearing on whether or not it is a good tool, or on its creators/community. I completely recognize and accept that my opinion of the tool and its creators is absolutely worthless.
So, I'm best off, keeping my mouth shut on the tool and its creators. I can live with that.
Since this was linked on the front page of HN, and seems to have remained up for four years, I can comment on what it says, in a very limited fashion, as there are a couple of things that resonate with me.
In my case, I'm the original author of a fairly important infrastructure tool, that has been completely taken over, and is being maintained, by a new team of highly capable individuals. I'm barely even a footnote on the project, and that suits me just fine. I pop into the Facebook group for the project, from time to time, and spew up a little historical anecdote, as a trivia exercise.
But I started writing that project in 2008, and released it in 2009. I then had to shepherd, maintain, evangelize, and defend the project for ten years, in a sizable community of, for lack of a better word, trolls. The project was meant to help them, and Serve their needs. Getting them to accept and embrace the tool was ... challenging. I was met with suspicion, hostility, entitled demands, condescension, hostile takeover attempts, insults, attacks of various types, etc.
Ahhh ... fun times.
But in the end, it worked out.
One of the reasons that I have all but walked away from the tool, is that ten years of keeping the pot boiling was exhausting. A lot of other stuff didn't get done, while I was working on that, and I had to hold myself back, in many ways. I also made a number of interpersonal mistakes, while evangelizing/defending the project, and learned some harsh, humbling, lessons about myself, and about others.
I am eternally grateful to the team that took the project over. I am sure that it is not their idea of a "perfect tool," but it gave them an excellent baseline, and they have extended it, far beyond my initial vision. It now Serves thousands and thousands of people daily. I was also able to soak up a lot of the bullets for them. I'm a pretty tough old coot, and knew what I was signing up for (I am intimately familiar with the target demographic). Now that it's an established project, and some of the new team are quite respected in the community, it is being treated well.
All that, to say, that I was tempted to write a manifesto like this, numerous times, but decided that it would only make things worse.
[I assert that: ]"Open source is a licensing and delivery mechanism, period."
That's nice but I think you are wrong. For me and the rest of the open source community, we quite like our sense of community. We may even become quite sarcastic should you continue to assert that we don't exist.
I think it’s more than that. The quality of a foundational project, like a language, hinges in very large parts on stability and long term decisions. Saying “no” is the primary defense tool here.
It is something that I’ve come to appreciate over the years, but didn’t really get initially. A message like this one gives me great confidence in trusting the project.
People are actually afraid to say that directly for fear they'll be forked out of their own project. It's a legitimate fear, but it's also a fair fork. OSS maintainers are not responsible to us, but neither are we responsible to them. That's not how gifts work. If your maintainer is having an emotional breakdown or just wants to do something else, you route around it.
Yup. The snippet I like best (which can act as a TLDR as well) from this is the following:
> 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.
Depending on what you want for your project, though, this isn't unilateral. If you want a supportive community of engaged users, you must engage with them in return. It's necessary in any relationship to accommodate or at least recognize the needs and desires of the other party. You cannot expect them to stay involved if your answer to everything is "take it or leave it".
I hasten to add that I am speaking in general. I am not familiar with Clojure and I am not saying that Rich Hickey and the Clojure project behave one way or the other.
this post is representative of the mental illness thats endemic today. First of all, I can start open source project for any reason that I want including all the reasons that he listed that I'm not entitled to. There are no rules and nobody can dictate it either here or elsewhere. Secondly it seems that your lack of education and understanding has led you to this spot and I encourage you to seek more education probably outside the area that you consider your area of expertise. Finally the author of this post made the vital mistake of having expectations of other people, this is the prime mistake most people make and leads to their unhappiness.
> 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.
Yet, you believe you are entitled to say how all of open source 'ought' to work. Does it refer to everyone but you?
It's been a while since I read this rant but I suspect you have projected the "all of open source" into your paraphrasing of what he said and that in fact he never purported to speak for all open source.
You are projecting your beliefs upon the structure of the article. In the actual article, Cognitect wasn't mentioned until five paragraphs later. The first five paragraphs talked exactly about open source in general terms not limited to Cognitech or to Clojure. What I quoted was the very first sentence.
What I pointed out through a rhetorical question is that the article's first sentence tells others their opinions of open source are limited, but the premise of that statement is that the author is separate from that rule and by the act of writing this statement is setting a broad opinion which others are not allowed to have, due to the same statement imposing a limitation on them.
I was pointing out that the first sentence of the article contains a contradiction in its premise.
This isn’t a contradiction - the claim is that the only entitlement one has with open source is that which is outlined in the licenses. This is objectively the floor across all projects. From there, entitlements are granted by project authors and sit outside those granted by the licenses. The error, which is sadly common, is to presume entitlements of the latter kind follow necessarily from the former.
The problem is that this is relying on equivocation around the word "entitlement." One type of "entitlement" is an actual right that you can fight over in court, it's called the license. The other type of "entitlement" is just a pejorative euphemism for the word "expectation." By slipping back and forth between those meanings, you can create the impression of a proof that people's expectations are a type of illegal assault.
The UN Declaration of Universal Human Rights, signed by the vast majority of nations says "Everyone has the right to freedom of opinion and expression; this right includes freedom to hold opinions without interference and to seek, receive and impart information and ideas through any media and regardless of frontiers." So I think he is in fact entitled to say how all of open source ought to work.
I don't see how I made your point. There is a big difference between freedom to express and freedom from compulsion. He hasn't claimed that others don't have freedom to express - he has claimed that their expectations of him don't entitle them to his labor.
Another right from that same document states, "No one shall be held in slavery or servitude; slavery and the slave trade shall be prohibited in all their forms."
> As a user of something open source you are not thereby entitled to anything at all.
Wait; I'm not even entitled to software not doing anything blatantly illegal on purpose, or perpetrating a privacy violation without my knowledge and consent?
Also, "open source" has an even greater focus on getting paid than "free software". Surely, if people are paid, certain entitlements exist between certain people, even if none of them happen to be the author.
E.g. if you use a phone that runs on a Linux kernel, you may be entitled to kernel security updates, at least for a certain support period.
By the way, as a user of closed source, you're not entitled to a heck of a lot, either; according to the reams of text in a typical license agreement. If the thing causes data loss, too bad for you, says the disclaimer.
> Wait; I'm not even entitled to software not doing anything blatantly illegal on purpose, or perpetrating a privacy violation without my knowledge and consent?
Exactly! Try to reading through the licenses of the code you pull in, and it'll be evident. Here is a excerpt from the MIT license
> THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED
If the code you randomly pulled down from GitHub puts your computer on fire, you're the only one responsible for that happening.
> Also, "open source" has an even greater focus on getting paid than "free software".
Does it? Which Open Source license has any focus on getting paid at all? You seem to mix up "development/funding model" with "distribution license", where Open Source is the latter, not the former.
> Surely, if people are paid, certain entitlements exist between certain people
Depends on the funding model. Open Collective, Patreon and GitHub Sponsors are all donations, where you donate without any expectations of getting anything at all back.
> E.g. if you use a phone that runs on a Linux kernel, you may be entitled to kernel security updates, at least for a certain support period.
Sure, you probably are, but not from the Linux kernel, but from whoever you bought the phone from/your carrier. This article is about the kind of people write software like the Kernel, not the people who sell your products using FOSS.
> If the code you randomly pulled down from GitHub puts your computer on fire, you're the only one responsible for that happening.
That's what's the license says, but your local laws and regulations might disagree, and your license does not overrule the law.
Distributing malware is illegal and malware is defined differently in different countries. If you intend to upload sketchy code, make sure you've read up on what constitutes as cybercrime where you live because one of your victims may go to the police.
To make a flawed comparison: setting up a stand with cookies that happen to be poisoned next to a sign that reads "cookies free to be eaten at your own risk" don't necessarily let you go free when someone ends up in a hospital.
Now, as a counter argument, your average commercial OS is packed full of what would've constituted spyware twenty years ago, so you're probably free to package some types of malware. I don't know if what the colors.js guy did was illegal (at least he reminded people oftthe dangers of npm, which everyone then proceeded to forget) but I think he got away without a lawsuit. I doubt he'd gotten away would he have lived where I live, though.
I wonder if anyone has actually been charged based on malicious open source contributions. Off the cuff, it seems unlikely -- the person whose computer was damaged would have to navigate multiply jurisdictions and explain something technical to a court, likely as an individual.
The precursors to such a situation don't have to be exceptionaly unusual. It could be someone working in a language that is not normally compiled ahead of time and shipped in binary form (e.g. malicious Javascript). Even if not accompanied by a license, the code just has to use pieces of some open source work so that it is a derived work. That malware author is then effectively a contributing author, whether aware of it or not.
> the person whose computer was damaged would have to navigate multiply jurisdictions and explain something technical to a court, likely as an individual.
Easily done if the person is actually a mega corporation.
Though [re-reading parent] if we are specifically concerned with contributions that were accepted by a non-malicious upstream under good faith and then turned out to be malicious, then that is something else.
1. Not all the content of a warranty disclaimer holds in all legal jurisdictions. Giving people free stuff doesn't absolve you of liability for harm. Not everyone who uses some open source thing is aware of it; it may have been installed by someone else.
2. By open source having "more of a focus on getting paid", what I mean is that the term taken over and capitalized as Open Source by some people in the 1990' who wanted to distance themselves from the GNU project's rhetoric about freedom in order to emphasize the commercial viability of free software development. They formed something called the Open Source Definition. It's fair to call having more of a "focus on getting paid" than free software in the GNU sense.
3. Not all money for work on open source is donation. People working on it sometimes get regular salaries. Customers sometimes pay for it in the form of commercial products.
4. Chances are high that whoever you buy your phone from does kernel development. Just about the only way they could avoid it would be to license the SoC/board from someone else who does (and then they are almost certainly entitled to support).
> Wait; I'm not even entitled to software not doing anything blatantly illegal on purpose, or perpetrating a privacy violation without my knowledge and consent?
Tor is an open source project and I very well expect that, in some jurisdictions, what Tor is explicitly trying to do... on purpose... would be considered illegal. I expect that the people running the Tor Project know that. I could even speculate that some Tor Project team members are hopeful that their effort facilitates private communication in the very places where such communication is likely to run most afoul of the law. Worse than that, laws are often ambiguous, fuzzy, and contradictory within a jurisdiction, let alone between different jurisdictions.
So what does that mean to the entitlement that open source software does nothing blatantly illegal? I guess you can claim it, but I wouldn't expect much to come of it even assuming the project is being run with good intentions, nor would I count on it matching my expectations for same. I think it's better to not only discount legality as an entitlement, but not even hold it as an expectation. Legality is a decision point for the potential user, not a user entitlement the developers are duty bound to deliver to any one user.
> Tor is an open source project and I very well expect that, in some jurisdictions, what Tor is explicitly trying to do... on purpose... would be considered illegal.
But that's something the user wants, as a feature. It may be the user who is deemed to be doing something illegal.
The only thing to which you are entitled–by definition–is access to the source. It is your responsibility to verify what the source does.
The "getting paid" notion is off-topic and has nothing to do with the source being open. If I provide commercial support for someone and implement a solution using open source software, I am the one providing the support and I have no expectation that the original authors will hold my hand.
You're not even entitled to have access to the source.
If repository is down or if you don't know how to use git and demand updates being sent to you as zip files on your email - your demands mean nothing, you are not entitled to be given access to the source code.
You have _permission_ to use it in some license limited way and that's all.
If you _use_ open source code (ie. as part of your product), you may be _required_ to also provide source code, attribution etc.
That depends on the licence, though. GPL3 requires that obtaining a license should not be harder than obtaining the binary distribution. If you use some kind of obscure version control system for your source code but link the binaries in your website, you're entitled to the source code in a similarly easy way.
The developer could exercise their rights and insist on sending you a DVD with the source code on it (and make you pay for materials+shipping) but throwing up difficult burdens is clearly forbidden by the GPL.
Some more extreme licenses grant you, as a user and as a developer, a lot of rights, but also a lot of burdens. I don't think the stricter ideological licenses such as GPL are used much by people who distribute their own code and then decide to make life difficult for their users, though. It's likely that the only cases where this rings true are people relying on GPL code that then want to avoid fulfilling their obligations to their customers.
Most free software licenses don't concern themselves with use, except that they may make it clear that use is not restricted in any way. A license that restricts use in any way is probably not free.
> you are not entitled to be given access to the source code.
If you're the user of a binary image someone spun from a GNU licensed program, actually you are entitled to that, if it is the Affero license (AGPL), you may be entitled to source code access even if you just use the thing as an online service. Specifically, you're entitled to access to the source code of the modified version that you're actually using.
> If you _use_ open source code (ie. as part of your product), you may be _required_ to also provide source code, attribution etc.
That's redistribution. If you redistribute some kinds of open source code in a product, you may have to provide source code, and that's even if that code is never called. The presence of that code in the image is the key thing, not whether it is used. Use occurs on the target system, by the end user.
That "we" which refers to "you" may be talking about that; I'm talking about nothing other than the claim that users have no entitlements of any kind whatsoever.
One of the main takeaways personally from this post, is the unique position Clojure (and other lisps) are in, where language additions can be done as libraries instead of changing the core of the language.
Other languages don't (always) have this possibility.
Taking TypeScript as one example. If 20% of users want to be able to do something in TypeScript that the language doesn't support, they either can try to get the change into the core language, or live without it (or fork it). If it changes, it'll change for everyone using TypeScript
But in Clojure (lisps in general), you don't have this restriction, so modifying the language for your own need, becomes a lot easier. Lots of work on Clojure is simply done in libraries, as it's possible and doesn't impact the core of the language, which everyone shares.