Open source is not about you (2018)
gist.github.com
gist.github.com
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.
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:
- https://github.com/clojure/core.async/blob/master/examples/w...
- https://github.com/weavejester/compojure
- https://github.com/ptaoussanis/timbre
- https://github.com/krisajenkins/yesql
Furthermore, macros enables APIs like this, that would be impossible to have in JavaScript for example:
(spy :info (* 5 4 3 2 1)) => 120
%> 15-Jun-13 19:19:13 localhost INFO [my-app.core] - (* 5 4 3 2 1) => 120
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...
Usage:
(defn my-async-fn [foo]
(js-await [the-result (promise-producing-call foo)]
(doing-something-with-the-result the-result)
(catch failure
(prn [:oh-oh failure])))
In any event, they’re ripped out now. But ultimately macros offer a lot more in theory than in practice.
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 actually agree with most of what this guy is saying, but the delivery is not good.
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.
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.
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.
Does my comment came across like that because I point out benefits from using Clojure, or what makes you say that?
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.
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.
No, it's about Clojure. It's not in any way about open source. Software can be open source no matter how the person writing it runs their projects.
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.
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.
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.
> 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.
> 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.
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.
Only thing worse than submitting a patch and being ignored is watching someone else commit the feature or fix in spite of the contribution.
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.
This is license specific. You can create an open source project which does not allow forking.
Edit: Notably it seems some commenters here confuse the idea that FLOSS will allow for forking but open source does not necessarily do so.
[0] https://en.wikipedia.org/wiki/Free_and_open-source_software#...
[1] https://web.archive.org/web/20021001164015/http://www.openso...
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: A text by the other side of that conflict
https://www.gnu.org/philosophy/free-software-for-freedom.htm...
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)
But I don't think anybody is interested in talking about your dog.
I however assumed you have another definition.
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).
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.
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).
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.
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?
*edit: there is some context here https://news.ycombinator.com/item?id=31958698
I wish I understood this earlier in my life.
You aren't entitled to know that ;)
You know, I don't think I've ever participated in a conversation that used the word "entitlement" and came away a better person.
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.
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.
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.
Many contribute fixes and actively improve the software, but many post entitled comments.
Except there is no implicit guarantee.
For example the Apache 2.0 license outright says it, so there is no argument about "implicit guarantees"
https://www.apache.org/licenses/LICENSE-2.0
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
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.
Open Source isn't all about you, but it is a little bit about you.
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)
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."
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 wish advertisers would understand that.
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!
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.
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.
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?
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.
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.
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.
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.
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.
>> * 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.
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.
>> 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.
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.
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.
1. i.e. there is no definition in law to what this means.
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.
An open source developer does have a duty to not mislead their users or publish malware.
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 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.
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:
https://github.com/matheusmoreira/ite-829x
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.
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.
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.
You'd think that people working on FOSS are aware of this pattern and watch out for it. But seemingly not!
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”
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.
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 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.
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.
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.
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
That's a detail that, even if specifically was mentioned, would be overshadowed by the main sentiment.
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.
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.
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.
There is this blogpost as well about the "half-life of code": https://erikbern.com/2016/12/05/the-half-life-of-code.html
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.
I don't know if Scala or FastAPI suffer from feature creep though.
I think this is the original post from Timothy Baldridge: "Contributing to Clojure" - https://gist.github.com/halgari/c17f378718cbd2fd82324002133e...
> 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.
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.
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.
Open source is about you, or could be about you, if you find the right kind of open source community.
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.
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 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.
On the other hand, ignoring the merely annoying is free. And happens to me all the time.
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.
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.
https://gist.github.com/halgari/c17f378718cbd2fd82324002133e...
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.
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.
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.
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.
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.
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.
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.
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%.
The rest of the post would be good if not for this crack that lets the rot in.
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.
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 think, in my case, that was a good decision.
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.
And quite right too.
> 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.
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.
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.
Other licenses are available.
Yet, you believe you are entitled to say how all of open source 'ought' to work. Does it refer to everyone but you?
I was pointing out that the first sentence of the article contains a contradiction in its premise.
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."
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.
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.
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.
> 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.
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).
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.
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.
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.
> 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.
If you're an author of a library you have the right to not accept contributions, stop working on it or delete it from github.
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.
But that's something the user wants, as a feature. It may be the user who is deemed to be doing something illegal.