Though Rich is right, it pains me to read this because it is indicative of some disputes in the clojure community. I might be mistaken, but it seems that Rich is reacting to Chas Emericks' twitter post (https://twitter.com/cemerick/status/1067111260611850240).
In his comments he has stated: "Finally, from a practical perspective, my core-level contributions always came from some source of pressing need in an actual, present, needs-to-work project. If I know a problem isn't going to be triaged for months and solved for years, then I'm out."
So this is not some grieving random person from crowd - Chas is a person whose libraries and contributions I value tremendously and he certainly made LOTS of contributions to clojure OSS landscape for free and out of his good will as well.
So ultimately this feels like your parents are arguing (which is never a good thing) - you like them both and you just want the arguing to stop and you just want everybody to live together in harmony. But here you go, Chas has moved away from clojure now. And I have to say I am very sorry to see him go.
Rather than reply to any of the various downthread issues, just a few clarifications:
* I don't know exactly who Rich is responding to, but I can't imagine it's for rando users who drop off drive-by TODOs for maintainers. More likely IMO it's in response to a number of people who have contributed significantly to clojure itself and to supporting projects and resources that have spoken up in recent times with various critiques.
* I'm super uncomfortable with any comparison to this kind of "dispute" as being anything like that between parents, etc., though I can see how some might think of it like that. Really, it's a disconnect of expectations and a lack of communication, which I'm glad has been resolved definitively.
* I do still use Clojure (though more via ClojureScript than otherwise), it's just not my primary rig anymore, and I'm strictly a user. The contribution process was a minor factor, not the driving rationale for my looking elsewhere; though, as I said in the posted tweets, I surely wouldn't have tarried so long if I knew earlier what I know now.
Thanks Chas for responding. Apologies for the parents metaphor if that made you feel uncomfortable - since at the time of my writing lots of comments on gist and HN were concurring with Rich and talking about "weeding out toxic personalities" I was just trying to come up with a metaphor that would offer a different perspective - that this is a type of disconnect that benefits no one and that there is no side that is clearly "good" or "bad" since all sides are needed for the whole ecosystem to work. Rich's statement was aimed at some core contributors (I am guessing now probably a bit more at Tim and less at your follow up tweet) and that worries me. Imho this situation is a lose-lose scenario: for Cognitect to lose contributors, for contributors to have spent hundreds/thousands of hours in vain and for anyone from clojure community who placed his bet on clojure and invested substantial time in learning/using/evangelizing it (affecting his/her market value in the process).
Anyway thanks for all the work on clojure! I am still using some of your clojure libraries!
Normal people who are using the software to get something done just maintain a local fork where they can fix fires as fast as they want, then treat upstreaming (if any) as a background task that is allowed to take the necessary time.
E.g. numerous GNU/Linux distros maintain local patches for numerous packages: kernel, gcc, glibc, ...
Some of these take years to get upstreamed, if at all.
The problem is that this process doesn't work so well for people who just want to leave their imprint on that project (that one and only official project, not their private fork).
Saying I'm not going to use this as my main tool if I can't have a more or less free reign in shaping the destiny of its one and only official version comes across as a bit of an infantile tantrum.
> "If I know a problem isn't going to be triaged for months and solved for years, then I'm out."
Some problems are easy, low hanging, do it yourself. I guess that's not the issue here, but it's worth mentioning as a lot of OSS projects don't cater to solving these. (Expose some little bit from an underlying lib, make something configurable, etc.) And there are the uh-oh we have to refactor half of our codebase to solve that one by the way totally valid problem. And that's usually not a one weekend "project", and it is understandable, that it might take years.
And at that point, I feel that the entitlement of "make this work for me, because there's a project that depends on it" is the problem. Sucks to be the guy who have chosen the wrong tool, even if it looked like the best tool. It happens all the time.
> As someone not in the know, Rich's post seems like an extremely aggressive and arrogant piece.
It seems that way? To me, it seems like a reasonable response to how many people treat any kind of volunteer-led effort.
For example, I help mod a fairly popular subreddit, r/cscareerquestions. Now, we don't have a problem with people suggesting changes to sub rules or have meta discussions and even complaints. No community is perfect, the mods certainly aren't, etc.
However, the vast majority of complaints are of the completely useless variety. They're the vague one-liners -- "this sub used to be good, and is now bad for generic reasons I will not elaborate on" -- that usually have no clear basis in reality, nor any practical solutions even to the extent they're true.
And when I try to earnestly engage with people who have the most upvoted complaints, 95%+ of the time, there's nothing there. Probably half the time they just don't respond, half the remaining time they just loose another snipe or parting shot before disappearing, and most of the rest is something in the set of {doesn't actually happen/no evidence; assumes everyone agrees with them; problem is actually well-diagnosed but the proposed solutions are laughably naive}. The number of complaints or suggestions that are meaningfully actionable is very, very low.
What I've found looking at other subs and ours, is that generic complaints about sub quality and mod team actions are a quick and easy way to upvotes, but it's rare for someone to actually be well-informed on the topic and have actually thought through the problem and solutions they suggest.
So when Rich says, "Did you know that most patches/issues have poor problem statements, no description of the plan (read my code!), no consideration of alternatives, no tests, no designs, and are ill-conceived and/or broken in some way?" that doesn't surprise me in the least. Even when people nominally want to contribute, they usually don't seem to try very hard. For me, it's gotten to the point where I'm writing a guide for subreddit criticism and suggestions to try and improve the quality of the complaining.
tl;dr - even when something is reasonably well run by volunteers, people love their low-effort gripes and snipes
I don't have any reason to doubt the truth and logic consistency of either Rich's post or your reply. The problem is not the logic, it's the rhetoric. For anyone out of the loop, he sounds like an interstellar douchebag. And, because the article is public, this can become a problem.
In my experience there are two kinds of people. Those who focus on tone and delivery, and those who focus on content and consistency.
The former will remain exceedingly polite, up to and including the part where they tell you to go f yourself.
The latter are the ones you can actually depend on in a crisis, because they won't be busy playing social games to cover their own behind.
I'd argue that if someone is seen as a giant douche because they won't automatically cater to someone's sensibilities, that's a sign of a real douche, who is so used to being marketed to and "handled", that fair, reciprocal treatment is experienced as rudeness.
That is the gap between the kind of culture open source used to have, and what some want to turn it into today, and which is often incorrectly dismissed as a lack of civility.
Civility is that which allowed civilization to form, not what passes for it once others have already done the work. If that is a problem, it's because it's been manufactured into one on purpose.
> Those who focus on tone and delivery, and those who focus on content and consistency.
This is false dichotomy. Overwhelming majority of people care about both. When your tone and delivery is insulting or diminishing them, they see it and react to that too - those who don't tend to end up bullied and disrespected.
Also people who dont care about tone and delivery quite often backstab. Just like they dont care about others while there is no crises, they care even less when crisis is there.
> For anyone out of the loop, he sounds like an interstellar douchebag. And, because the article is public, this can become a problem.
I'm out of the loop and didn't get this sense at all. His points seemed fair enough to me. There's way too much entitlement evident amongst people who use, and sometimes even contribute, to OSS[1]. It gets frustrating, and Rich has explained why.
[1] I've never been an maintainer of a popular OSS project, and don't want to be, but a few years ago I was a custodian for a relatively popular free (as in beer, not as in speech) tool, and we'd often get emails from users acting like we owed them something.
I’m not in any loop and nothing about the post came across as douchey. In fact, it seems many people need to be reminded about who is responsible for putting open source code in any project especially after reading the disgustingly entitled comment thread on the recent nodejs security issue.
You think its disgustingly douchey for people to be dismayed that software from a trustworthy dev was turned over to someone who turned it into malware?
The dev isn't responsible for the giant mound of stupid that is npm but we all have to take the world as we find it or fix it.
In the context of the world as it is projects deps having deps having deps where the practical protection against a developers machine getting pwned and eventually millions of users getting pwned is more or less developers checking to ascertain that a given library is bob who works for google and not lame hacker number 2388 its poorly considered to hand over libraries to people you have no reason to suppose are trustworthy. A reasonable person could suppose that might not end well for a multitude of projects where 182 deps of deps of deps aren't vetted again per point release because in practical fact its impractical to do so while it is very practical for individual authors to not transfer control of names and publish info about their authorship.
Unlike never updating or expecting individual orgs to vet 182 deps written by anon people with every bump so a reasonable person ought to do their best to make the workflow that might have some hope of working work.
If you didn't want ANY responsibility whatsoever you could have not published it globally.
Anyone who imagines that responsibility is merely transcriptional that it only attaches when money changes hands has literally missed the majority of human civilization including the more recent parts where people that give away free food are still expected to wash their hands, get food handlers cards, practice food safety, pass inspections etc. You aren't required to provide a vegan or kosher option or even make good food but you can't behave maliciously or negligently.
Given how projects are actually used by virtually everyone authors actions appear negligent. Given the hypothetical bad actually already happened it appears that judgement is irrefutable.
You are your brothers keeper whether you want to be or not. Software isn't special it works like every other civilized endeavor. Wash your hands and don't scratch your ass please.
In the context I work, I expect external software to be audited when incorporated into a project. It should be a significant decision backed by clear rationale to depend on someone else’s code not simply a convenience because we’re all lazy devs. I review diffs when updating library versions and guide people to prefer writing in-house solutions over including pop-software libraries. I hold my team accountable for the software they produce. I don’t disagree that everything works better when we all play nice, but I also don’t agree with deflecting the blame when your software is compromised because it doesn’t actually solve the problem and allows the same poor habits to continue unchecked. If you don’t understand a dependency enough to implement it yourself were it to disappear or break, you shouldn’t be using it.
Also, er, bloody hell. These comments are completely out of hand. Examples:
"You put at risk millions of people, and making something for free, but public, means you are responsible for the package."
"There is a huge difference between not maintaining a repo/package, vs giving it away to a hacker (which actually takes more effort than doing nothing), then denying all responsibility to fix it when it affects millions of innocent people."
The person in question isn't some random dude who just makes demands, but a visible volunteer. Otherwise the tweet would have no voice, and Rich Hickey wouldn't feel like spending the time to tell someone how they weren't worth the time.
But honestly the stakes are higher than video games. If you go around advertising your package, get people to depend on it, then compromise them later, that's malpractice on your part. That isn't how society runs so it's rather obvious when people get mad that there's a landscape full of anarchy when it should look more like modern civilization.
Like it or not, npm and the node community has not prioritized its reputation. And the mechanisms that keeps bad operators out of npm open source rely on a relatively small company considering the actual business livelihood that relies on npm integrity. It means the community is okay with continuing to use npm, and that means that the community doesn't have a healthy way to maintain itself and build trust. It's going to rot, I think (and hope). It's just going to be a bunch of tribal nomads moving from project to project until someone social engineers a compromise and they're off to find another huge dependency graph again.
At the very least, Clojure is telling people what it's about upfront.
Other package managers are not immune to this, btw. npm is just often the whipping boy.
> If you go around advertising your package, get people to depend on it, then compromise them later, that's malpractice on your part.
I tend to agree with this. I've always had a great deal of sympathy with OSS devs and maintainers, but if you've gone out of your way to evangelise people onto your platform (OSS or otherwise), then leave them high and dry, resulting in a load of complaints/bitterness, you have to bear at least some of the responsibility for that outcome.
> If you go around advertising your package, get people to depend on it, then compromise them later, that's malpractice on your part.
I'm not sure how much he advertised it.
This is part of the problem I have with things like npm, cargo, etc.
They defaults are set to try to suck up your work and get you to make it public.
Consequently, semi-useful things get loose probably long before people intended them to and probably long before people realize how much work they just signed up for.
That was a different issue IMO. I've stopped maintaining open source projects that others rely on, and I owe them nothing. They can fork my code if they like.
And yes, it's users' responsibility to decide what code they trust. But "I trust developer/organization X" is a reasonable way to decide that, and auditing every single release is far, far more expensive. I'd be betraying their trust if I let a complete stranger release an update in my name.
He clearly really cares about Clojure discouraging people from freeloading may be beneficial but a crummy tone may discourage people from adding value to Clojure which would be very unfortunate.
> Though Rich is right, it pains me to read this because it is indicative of some disputes in the clojure community.
I am genuinely curious why you, or anyone else, would think he is right. I can see why people would agree or why he wants to do things a certain way, but to be right you have to have arguments backing up what you are saying. I don't see that in this post. Am I missing something?
> I am genuinely curious why you, or anyone else, would think he is right.
Because Rich has the rights to do what he wants with his time and money. (Like everybody else.) It is completely within his rights to establish his own governance and contribution model for his version of Clojure. At the very least, I don't see an argument why it's NOT within his rights to do so.
Of course, there are several corollaries. The first is that nobody is forced to use or contribute to Clojure. The second is that, given that Clojure is Free Software, it's possible for someone else to pick up the baton, make a fork, and run it their own way. (egcs and XEmacs both come to mind as examples where someone did this and it wound up improving the original.... so there _is_ precedent.)
I wouldn't feel terribly bad if someone made this fork, but I'm not going to do it myself. Unlike Rich, I'm not willing at the moment to make the personal sacrifices that'd be required to make this sort of contribution. Neither, apparently, is anyone else.
So Rich gets to make the rules. Because he (and Cognitect) have paid the dues. Whether that's good for Clojure in the long run remains to be seen. (But honestly, my semi-informed take on the ecosystem is that it needs library maintenance much more than it does core language improvements. The core language has been an excellent choice for many purposes for years.)
I don't know much about the Clojure community... but this article says "Open Source Is Not About You." If this is the generic "you," ie the random user that's coming in and complaining about something, then sure.
If this is a veiled criticism at a major contributor to the community, then I think it's disingenuous. If you're trying to foster a community around your OSS project/product (and Cognitect is doing just that) then you take on a set of obligations to that community, especially those who contribute code to it in good faith.
I understand that this is his position, what I don't see is his reasoning.
If everyone is free to do what they want with their own time and money, they are also free to condition their participation in the project. As far as I can tell that is not what he is saying though. What he is saying is that you are not entitled to anything, meaning that you can't expect anything for your participation.
If he had just said that he runs the project how he want and people can "take it or leave it" that would be another thing. But as I read it he is specially questions the right of others to question the project. Essentially saying that they don't have that right. It is this position I don't see him backing up with an argument.
> Having a right to do something is completely orthogonal to whether you should do that thing.
Yeah... there are really several conversations that could be had:
1. Rich deserves credit and respect for personally taking on a cost that ranges into the hundreds of thousands of dollars to fund Clojure. Very few people do this, and even fewer bring the taste and judgement Rich brought to Clojure.
2. Rich/Cognitect currently own the Clojure governance model and they can do with it what they want.
3. Maybe the current governance model isn't what's going to bring Clojure the next 20-30 years of viability.
My take on it essentially this:
1. Yes. I wouldn't/couldn't do it myself. (And I've started down the path at least once.)
2. Yup. Maybe it will be what the platform needs to grow and thrive. Maybe not. Maybe it will be attractive to users and developers. Maybe not.
3. At some point, this will probably be true. Given the history of companies and projects, this shouldn't be a surprise.
I mean, he is right about open-source only being a binding license for the source, and in this case, the Eclipse 1.0 license in no way entitle users too any kind of support, decision making authority, opinion, voice, or any other such thing.
That part of what Rich is saying is pretty much indisputable.
The second part, is related to what is best for Clojure. And the argument is simple, Rich says what is best for Clojure is a thorough review process of all changes to its core and standard libs, with a very high bar towards contributors and their contribution. His argument is that this has worked so far, and has created the solid piece of software that is Clojure today. Thus its own success is proof that it is a good enough process and is good for Clojure.
The argument against is that contributors find it too hard and too much work and thus very little contributors make it through the process. Though I didn't really see them mention any alternative process suggestion. It seems they were mostly wanted their patch to just be merged in without challenge.
Yes; it’s definitely less convenient to write and maintain your own software compared to having someone else do it for you.
As a project maintainer I’ve made the mistake several times of being too permissive with pull requests. Someone comes along with a feature they’re excited to add to my project. I don’t need the feature myself. They exuberantly make a PR, and I eventually merge it. Before long it turns out there’s a bunch of bugs with that feature, and the original author is gone. Do I waste my time fixing their code, for a feature I never wanted and don’t use? Or do I ignore the bugs and let the smell of low quality work waft over my code base?
These days I default to refusing most feature requests, even if they have decent PRs. I write most software for fun, or to scratch an itch. I don’t do it because I want to manage a community. If you want to add features and build a community around a project I’ve written, great. I’m happy to link to your fork in my readme.
Forking is not a symptom of failure. Maintaining a fork is sometimes just the ticket price to control your destiny.
You can fork, fix the issue, and issue a pull request and/or start a discussion about the issue and potential fix. That is the core of open source - not demand that others fix the underlying issue for your problem.
No, he's saying a person who is thinking about results for the Clojure community wouldn't take things that way. Not everyone wishes to fork the community. Politicians step down from issues just because the timing is wrong and would be factious, not because the issue is wrong.
Also the person in question is also a well-received volunteer, which is why this is getting traction to begin with, which is why Rich Hickey would even take the time to tell someone that they aren't worth the time of the very response they're reading.
"which is why Rich Hickey would even take the time to tell someone that they aren't worth the time of the very response they're reading"
I think you are misrepresenting what Rich wrote. He said you are not "entitled" to a response. That is not an evaluation of someone's worth, but a statement about what they are owed, or not owed.
So you're asking someone else to do that work for you. Look, the user has a few choices:
1) find a work-around (maybe unwind his or her own mess)
2) manage a fork
3) work with the existing process
I've worked around people doing all three of these options but what I've regularly found was that taking a look at unwinding your own mess is the right approach for the vast majority of cases.
No. Whoever is leaving should have left without ranting is the only issue I'm having with this aggravating distraction. Chas knows very well how Clojure is authored. I suppose some people believe their contributions or community status give them higher authority and a right to publicly pressure Rich Hickey. But in reality they are only doing more damage to the community and likely Richs creative process on the way out. If this is the price for their contributions I want to live without them without even thinking about it.
As a power user, to me this doesn't appear to be a community issue. A handful of individuals take themselves way too seriously and don't realize how they are hurting someone emotionally.
The entire idea that a different process would produce better results is an insult in the first place. The progress and effect we got with Clojure with no enterprise funding/influence is a true miracle.
> Chas knows very well how Clojure is authored. I suppose some people believe their contributions or community status give them higher authority and a right to publicly pressure Rich Hickey.
Thought experiment: assume for a moment Rich is now running Clojure into the ground, and this is a bad thing. Who are the people that _do_ have standing to try speak up and make things better? If not Chas, who?
> The entire idea that a different process would produce better results is an insult in the first place.
No, it's not. Projects grow in complexity as they are used. It is only natural that they require improving governance models as this happens.
Another thought experiment: Name another successful open source project that's stayed on the same sort of governance model throughout the first ten years of its existence. These all usually work the same way: there's an initial individually driven chunk of core development and then the process broadens out to a more community driven effort. (With individually driven spikes along the way that are contributed into the whole.)
It really reminds me of a phrase I heard fairly recently: "Go fast alone, go far together." At some point, a transition probably has to be made.
> The progress and effect we got with Clojure with no enterprise funding/influence is a true miracle.
True enough.
And now we're looking for the next true miracle: sustained development and use over the next twenty, thirty, or more years.
This thread made me look at Clojure again (it has been a few years since the last time). Searching for Bayesian inference libraries I came across this: https://github.com/cemerick/raposo
"Never, ever, ever give a talk about a library or other code publicly unless it's in a public repo prior to the talk. Period. (Exceptions to this might be things like case studies and such.) Doing otherwise is surely irritating to talk attendees, but it's even more disrespectful towards organizers, as their acceptance of your talk may have been implicitly preconditioned on the attendees being able to benefit from the code/library/project in question."
Is the expectation now that when you talk about something it is necessarily going to be open source? (And from there the expectations grow and grow...)
The author is saying those things about his own talks, not generally of everyone. Unless you're trying to claim they are never true in any case, I don't think there's anything to disagree about here.
I understood that the attendance’s irritarion and the “acceptance of your talk may have been implicitly preconditioned on the attendees being able to benefit from the code/library/project in question" would also apply to someone else’s talks. But I see how the availability aspect could be part of his talk, or is expected because of who he is. If it’s about himself/his talks in particular another option would be to change the expectations.
I think you're over-parsing this. The document you linked is basically an apology - the guy's saying "if you came to this repo looking for the code for that talk I gave, it's not here, and sorry about that, and here's why I regret that and how I'll avoid repeating my mistake". Considered in context, it's clearly not a "here's what I think other people ought to do" kind of document.
> the “people find presentations about code or libaries for which the source is not available irritating” seems to be a general statement.
Read the whole thing in context. He's apologizing for jumping the gun - for giving a talk about a library he intended to release, before it was ready. The implication is that it was probably a "hey try this library!" kind of talk, that has little value to the audience without the code, so he's saying he should have waited.
Giving talks about closed code that will never be released is separate from all that, and clearly not what he's talking about. Hence the exception, "case studies and such".
Fine, I see how it can mean that. But even reading it in context I don’t think that “the implication” was obvious. Of course, a talk based of unfulfilled promises can be irritating. It’s a good thing to avoid. No disagreement on that.
Sometimes I hear presentations just to learn how they approached a problem remotely similar to mine or used tools I am interested in using myself. The library and its exact implementation are mostly irrelevant in that case.
One thing that I've found increasingly distasteful (I've noticed it in the React community, but it may be a wider trend), is the use of conference talks to announce/launch projects.
Thankfully it's still usually the case that the content of the talk is generally valuable. But ultimately, if I'm paying to fly somewhere and see your talk, I'm there to learn, not to witness your own self-promotion.
I guess it's no worse than the other main use of conference talks I've seen, which is to hawk the speaker's latest book. Maybe that's diminished somewhat, I have not been to many conferences lately but 10-15 years ago it seemed like most talks were peppered with phrases like "I talk more about this in my book..."
It's possible I was lucky with some of the conferences I went to, which had talks very much in the vein of "here's a new/different way to think about things". And I don't mind people using their own projects/products as a demonstration of what they're trying to communicate. But when they start to feel like Apple's product announcement keynotes, it feels something has gone wrong.
> You are responsible for your own needs. If you want things, make them.
>I am grateful for the contributions of the community. Every Clojure release incorporates many contributions. [...] Open source is a no-strings-attached gift, and all participants should recognize it as such.
>The time to re-examine preconceptions about open source is right now. Morale erosion amongst creators is a real thing.
Sad that it has to be said. I think as a creator you need to brace yourself for the reality of what it means to offer something to the world. There is a sort of normal distribution of consumers and some can be surprisingly toxic.
Interestingly, this isn't just isolated to open source. I've heard similar sentiments expressed by artists of popular works, including but not limited to:
- Game developers
- Authors of popular novels that have yet to finish ("GRRM is not your bitch")
I had been doing that a long time when one of my producers (on his first game) wanted to be on the forums to interact with "fans". I think he was excited and thought it would be satisfying to interact with people who were playing the game we developed. I remember thinking it would be like that when I started. Don't get me wrong, most gamers, like most people, are terrific. But they get drowned out by the disgruntled.
Then you better stick to that classical sales model that seems to be on the way out. The minute you sell the full package of an unfinished products, people will feel entitled to what they expect it to be (rightfully, imo). So you'd should avoid Pre-Purchase, Season Pass and some degree Early Access. I'm torn about the latter, since it is supposed to be sold "as is" with no expectations, but don't think this is was most actually do.
Also how do you think about post launch updates to fix bugs? Those seem to be generally expected as well, now.
> Also how do you think about post launch updates to fix bugs? Those seem to be generally expected as well, now.
Personally, I'd say the consumers are entitled to those, too. Your comment made me think of various games where I think that wasn't the case -- and that's mainly because those games were finished (and polished) before release.
I never expected any bugfixes for Games such as Starfox 64, Zeldas, Super Marios, and various others out of my old SNES and N64 cartriges. Because they worked. They were finished. Funny enough: Super Mario Odyssey had some a-ha moment for me because it also worked just fine literally out of the box, which is something I'm not seeing often enough anymore.
But honestly, launches nowadays are usually far more on the side of Games like Elder Scrolls: Oblivion than those examples.
Imagine a regular software engineer in $MARKET going "ugh, all these people we've sold buggy software to at full price now think they're entitled to bugfixes."
OTOH, there are of course some games where the effort put in by the developers far exceeds what any customer could reasonably expect. Terraria would be a great example for this.
With open source you have an easy recourse: the fork.
With a game, movie or another peice of culture, the law can hinder your fork. If you want to make the Star Wars episode you wish had existed, you have to navigate the tretcherous waters of fair use and copyright. There are also plenty of tales of indie game developers attempting to remix a game from their childhood on a new platform only to get a cease and desist as soon as the rights holders get wind of it.
Whether you are entitled to write fanfic is not a straightforward case. As https://en.wikipedia.org/wiki/Legal_issues_with_fan_fiction documents, some authors allow it, some don't, and fanfic sites pay close attention to who does. The fact that you can write Star Wars fanfic is not entitled under law, it is entitled by implicit or explicit permission from the copyright holder. Star Wars is OK. Pern? Not so much.
Oh, and sometimes you can both write and sell fanfic legally, no matter what the copyright holder thinks. For a famous example, Bored of the Rings is legal because it is marked as parody.
Moving on to open source, you are even more squarely wrong. The definition of open source, as found at https://opensource.org/osd-annotated, in item #6 says that commercial use must be allowed. In other words anyone is free to try to make money off of that open source project they forked as long as they follow the license.
In fact the term "open source" was invented as part of a marketing campaign to encourage the use of free software for commercial purposes. Far from "you can't make money from this", the whole intent was to encourage people to try to make money from it. And seeing that you could, to encourage businesses to make more of it! (This marketing campaign was successful, which is why you both have heard of the term some 20 years later, and everyone uses open source software.)
Now the license may restrict what business models are feasible. For example you can't edit GPL software then sell it as proprietary. But that is a MAY, not a MUST. As an example, selling relabeled BSD software commercially is both explicitly allowed and occasionally encouraged.
Cambodia is exempt from almost all copyright laws (deliberately, not as a tax-haven thing). If you want to write "illegal" fan-fic, just publish it in Cambodia.
Whether it's moral to do that, against the wishes of the original author, is another matter. Legal and moral are not the same thing.
You are not entitled to make money off it, just like you aren't entitled to make money off that open source project you forked.
You are absolutely entitled to make money off of an open source project you fork. As long as your fork provides value you that someone is willing to pay for.
> You are perfectly entitled to write that Star Wars fanfic.
Nope. It's a derivative work, and, as such, requires the permission of the people who own the copyright and trademarks.
> You are not entitled to make money off it
This matters less than you may think. There's a four-part test [1], and profit is considered, but the work not being for-profit doesn't make the work legal.
> Under current copyright law, nearly every cover song on YouTube is technically illegal. Every fan-made music video, every mashup album, every supercut, every fanfic story? Quite probably illegal, though largely untested in court.
> Image yourself an artist (of any sort) who has drawn such great inspiration from another (copyrighted) work that you would like to modify that work to create something new. Are you allowed to do so? Could you get a copyright to your new creation? As with most questions in law, the answer is: it depends.
> “A work consisting of editorial revisions, annotations, elaborations, or other modifications which, as a whole, represent an original work of authorship” (17 U.S.C. § 101) is called a Derivative Work. The original copyright owner typically has exclusive rights to “prepare derivative works based upon the copyrighted work” (17 U.S.C. § 106(2)). It is considered copyright infringement to make or sell derivative works without permission from the original owner, which is where licenses typically come into play.
Again... make or sell. Not making a profit off the work doesn't necessarily protect you.
The copyright and trademark owners may choose to ignore your little fanfic hobby. (Or they may not.)
In the case of open source software, you can fork it (or not) and--assuming you abide by the license terms--you can do anything you want including making money of it.
And that's the biggest misunderstood concept in free software. "Free" here doesn't mean free of money but freedom. FSF actually encourages requiring money for software.
Is there anyone that successfully does that though? I can only think of the Ardour DAW, which offers itself for a dollar so you can avoid trying to build gtk. It even offers a crippled, costless version.
Except you absolutely are allowed to make money from open source projects you fork. The only limiting factor is what license you need to provide with it (and potentially give up your new source code), but you can even make money from GPL code.
Isn't your second point precisely part of the difference? With an open source project and an appropriate license, you may very well be able to make money of a forked version of the project.
No OSI-approved open source license prohibits you from making money off an open source project (forked or otherwise). Though some licenses make it easier to take certain monetization paths than others.
As Carnegie used to write, "no one ever kicks a dead dog". Also, the more important the 'dog', the more satisfaction some people derive from kicking it. So unfounded and nasty criticism is probably best seen as validating that your work is making some impact.
I think it might be a part of any artistic endeavour: you'd probably have to have a list of creative efforts that don't have this problem to try to get a smaller list.
"The artist committing himself to his calling has volunteered for hell, whether he knows it or not. He will be dining for the duration on a diet of isolation, rejection, self-doubt, despair, ridicule, contempt, and humiliation."
This is the rational approach, but it is not in accordance with human nature.
Human nature is fanboys. Picture sports supporters. They will perceive a relationship that you may have never intended. They will wave your flag and they will sing your praise and they will cheer you on. And they will expect you to live up to the grandiose image they have of you, and will punish you when you "betray" them.
I think people are certainly taking note of these "entitled" comments when they decide what to get emotionally invested in. If I know ahead of time you "wont be my bitch" maybe I'll save myself some grief and not get started with your series.
Bitcoin is an interesting case. It has very deliberately rewarded it's early adopters and fanboys, and that strategy paid of very well.
Not the same thing at all - those are commercial products. If someone has paid for a product and feels it was missold then yes, they are entitled to leave a review. Especially since cinemas don’t offer refunds to dissatisfied customers.
You know, I wrote a number of successful open source packages. By and large, feedback is positive, or at least utilitarian: bug reports, feature requests, questions. But there is also the occasional angry user, or, rarely, a simple thank you.
Recently, I published my first-ever commercial video game plugin. And was dumbfounded by the sheer positivity of the response. People thanked me! I got dozens of purely positive emails. I had never experienced such a thing in my Open Source work.
If we had more of that in Open Source, maybe maintainership wouldn't be such a burden.
I wouldn't dare writing just to say "thank you", it would feel like a no-op wasting people time. Instead, I would rather star the project on github. Did you consider those as thanks?
Having published some apps a few years ago, the occasional thank you mail can be a real moral boost. Dehumanized interaction such as staring a project is not of the same category.
I totally get it, it's all a question of balance, I guess. An _occasional_ thanks you mail is great. On the other hand, getting pass the 100 stars on a project on github is a big moral boost too, and probably wouldn't feel so great if each one was a mail :)
But actually, I realize both can easily be reconciled : we could send a "thank you" message to projects with low amount of github stars, and just star those which have a high amount. This would both cheer solo dev starting their project and avoid annoying bigger teams on well established projects.
Has anyone ever been annoyed with a thank you email? Compared to the crap/spam/adverts that turns up in our inboxes every single day, a genuine thank you from an actual human being should be fine. And if not, just stick it in the spam folder with everything else. Github stars are utterly meaningless to many.
So I'll say that saying "thank you" is a highly valuable activity. It boosts people's spirits and makes them feel appreciated. Remember: we're humans and somewhat touchy feely. Gratitude is motor oil for us.
Also, tragically the world is wired to provide feedback mostly of the negative kind. This is useful to receive but also it's an unfortunate skew. Positive feedback with a few details about what is good are a hugely valuable contribution.
But if you don't have that amount of time, saying "thanks" alone is worth the keystrokes. :-)
Sadly (well at least to me) saying "thank you" for example in a github issue is considered next to spam. You can write a long description of an issue or solution and add "thank you" but it's considered a waste to say just say "thank you" when someone sends a small PR.
I disagree with that culture. I'd prefer we all exchanged the small "thank yous" even in github threads, code review, etc... but knowing the majority seem to feel it's spam I find most of the time I feel pressure not to write them.
Maybe a few "leaders" like Linus or whoever came out with "say thank you" would help?
Someone said bad words to you on the internet? Close your browser tab: you're done. Learn that you can't please everyone and you're better alone than with bad company.
I don't know if it's because a lot of drama queens and marketing people populate social media but it feels like most people can't fucking live without the approval of everyone when reading some websites.
If you want to bring conference in (it's IRL, can't close a tab) here is how to react: when someone start telling you shit, stop speaking, turn 180°, go join another group of people. It's rude? So what? Some person is now fuming while you're stress-free and engaging with better people.
Learn to ignore people. Learn to say no. You don't have to please anyone.
How do you know when you are interacting with one of "those people"? Even better, how can I join a conversation without being written off as one of them?
Yes , it's the reality, i think it's better for the creator to learn and act to be the actual dictator. This might mean ignoring those community suggestion/request that they don't like. kinda like linus which I admire.
The attitude of many is strangely feudal: "I (potential contributor) offer my fealty (using your code) to you (author), and in exchange you owe me protection (features)." These people are under the impression that authors ought to be impressed that somebody uses their code, which is not the case. Lots of users are nothing but a weight that drags you down: if you want to swim, you must cut them loose ASAP.
This is an excellent depiction of the distinction between "free software" and "open source" as ideological frameworks. As licensing schemes, they're the same - but open source ends at the licensing scheme, as the author correctly points out. If you want to use it for a side project, great. If you want to use it to make money, great. If you want to use it to commoditize the operating system for your worldwide advertising infrastructure, great. If you want to embed it in your iOS app or in iOS itself (and the license permits doing so), great.
We will be guided by the needs of our users and the free software community. We will place their interests first in our priorities.
We will give back to the free software community.
In other words, free software is about you.
I would quibble with the claim that the open-source process is what produced Clojure in the first place. The open source movement has benefited from sailing in the same direction as the free software movement and using the same tailwinds. Without the free software ethos (which was behind GNU as well as a lot of the Lisp work at MIT), would Clojure have been able to stand on the same shoulders, and would it have attracted the community of users and the ecosystem of libraries it has?
Or I would rather say... Yes, "free software" has an ideological intention, that is, to make the software free for all its users, to protect it from exploitation using a strong license, and eventually leads to some forms of social change in the software world, as in "when we have enough free software, we'll kick out those dirty licenses, ever more, hackers, ever more".
But "free software" itself is only the means to an end, it's a technical and legal tool to accomplish these ideological intentions, and as a tool, it's a collection of code published under a license scheme. When the developers served their duties by providing the source to the users, the work is done. The developers have no responsibilities to implement anything for its users.
On the other hand, if someone writes free software because they wants some forms of social change, in this sense, the intention is not solely developing free software, but to pursuit an ideology though the development of free software. And this is done by a group of people in a community, like Debian, then they must be doing whatever is needed for this goal, i.e. be guided by the needs of the users.
In conclusion, "free software" is not about you, a free software community can be, and often is about you. But it is also legitimate if it's not, in the end, it depends on the community. Some people only care about themselves, some projects just want mainly the software, but may also care about users freedom, some projects want social changes, while others focused on improving the current status of a specific technology. There are overlaps, but there are priorities as well.
I disagree. Software projects that claim to be free-software instead of opensource (plus use a "contagious" license such as GPL) don't owe you more community management than the ones with an MIT license.
Most high profile project that explicitly claim to be free software in fact do not do any kind of community management at all and do not tend to actively seek outside code contributions.
In fact the community involvement in development as exemplified by GitHub (and SourceForge before that) is to a large extent invention of the same group that started using the term open source (for what is otherwise mostly the same thing as free software).
The software that allows the GitHub style (light-forking) environment is called git, created by Linus. He's a great example of a person who doesn't care about free software ideologies, but cares about open sourcing code a lot.
And still, both his main projects (Linux and git) are under the most “ideological” license, the GPL. And the troubles he’s gone to, in order to keep this state of things in the face of commercial pressures on Linux, are almost biblical.
Linus cares a great deal, he just doesn’t want to be cornered as an FSF zealot.
I'm being a little unconventional with my terms - mostly because the article is titled "Open Source is Not About You." Zach Tellman (a prominent Clojure community member who does not work for Cognitect) just tweeted a link to his post https://medium.com/@ztellman/standing-in-the-shadow-of-giant... about "open source" and mythmaking, which is a much subtler take (and, I'd guess, probably inspired by an older flareup in the Clojure community over governance).
It is, however, the case that open source under the GPL is a perfectly well-defined concept, as is free software under the MIT license. The terms refer to worldviews about the code and ethical obligations, not to licenses.
Even in the world view of free software, regardless of the license being used, no community management is expected from the person that gives away the software they write. Free software is about the rights of the users (not the whims of developers/powerusers). Opensource is mainly just about transparency and efficiency of the development model.
This is why my code is licensed MIT. It is a gift, you owe me nothing, I owe you nothing. It might not work, it might not compile, it might delete all your files.
I could have written the same last sentences as you, but using a GPL license. No difference. Licensing is not related to this. (PS: When you choose "GPL", if someone modifies your software, they don't "owe" you those modifications; they only owe those modifications to their users, and only in case they have users. Again, no community-management here involved, just distributing the sources.)
> I would argue that the condition that you provide sources to your users is something you owe the author. But perhaps I'm over-philosophical.
No, I think you're right.
But you only owe it to the author if you're a "distributor". If you're a "user" (=a human who interacts with an application), you don't owe her anything.
The GPL keeps the distinction between the "users" and the "distributors".
This is important, because they have different interests ; They can't both simultaneously have complete freedom to do what they want.
If the "distributors" have the freedom not to redistribute the source code, then the "users" lose their freedom to study and modify the program (or to have it studied/modified by anyone competent - even software companies sometimes hire consultants to modify free software they don't feel like modifying themselves).
Basically:
- the GPL says to the users "do what you want", and says to the distributors "let the users do what they want (which implies: let them have the source code)".
- The MIT says to everyone "do what you want" (I'm omitting the copyright notice stuff here for brevity)
Thus, the MIT blurs this distinction "user"/"distributor" - which is fine, but creates lots of confusion when people try to understand the rationale behind the copyleft (leading to nonsensical reasonning like "there are things I can't do so GPL is less free!").
In that case, with MIT you owe the author some credits. (By experience, a lot of people won’t even honor that, even going to the trouble of erasing your copyright notice - literally the only thing they shouldn’t do...)
And only if their users receive a copy of the software in the process of using it. Source: Myself, who slings lots of technically-GPLed proprietary code in the form of network-accessible software like websites so never sees the light of day outside the customer's private repos.
Users must be able to readily obtain a copy of the source code. They don't have to receive it.
GPLv3 Section 6 d: "Convey the object code by offering access from a designated place (gratis or for a charge), and offer equivalent access to the Corresponding Source in the same way through the same place at no further charge. You need not require recipients to copy the Corresponding Source along with the object code."
No, I mean, if the "users" are on the other end of a socket and never receive any copy of the sofware (in any form) then they don't get the entitlement to the software in code form either. It's the problem AGPL was designed for.
From section 0: To “convey” a work means any kind of propagation that enables other parties to make or receive copies. Mere interaction with a user through a computer network, with no transfer of a copy, is not conveying.
If you give people someone free code and it deletes their files, you could be liable. That is why software licenses not only have permission-granting clauses but also warranty disclaimers. (Those might not protect you in every jurisdiction.)
I think you are reading too much into the term "free software" as GNU was historically[1] no less easier to contribute to than Clojure is today.
The GNU definition of free software (and the 4 freedoms) make it clear that it is about users, but only inasmuch as their private rights to do what they want on their own computers. There is no sense that openly welcoming community patches is something that is involved.
1: It's entirely possible that the community has opened up more recently, but Lucid shipped a fork of Emacs in the 80s for similar reasons to the complaints about clojure today.
This is entirely orthogonal. Free software is ideological by design. Rich here is complaining that the culture surrounding open source grew its own ideology, and that it interferes with the very process & value proposition of open source software.
Rich Hickey has given so much to the world of software and systems design. The value exchange has most likely not been reciprocal. Nor has it been sufficiently respectful, based on this message. People like Rich that give so much are rare. And people that understand how to respectfully recognize that seem to be becoming more rare.
Of course, one can remember that life is not fair, and people are often shitty even without being conscious of it, and that Rich has freely chosen to pursue this path.
But this leads me to a few questions: If you agree with what I have written above, and what Rich has written in this message, then how can we tip the scales just a little bit further towards respect and reciprocation? What kind of gestures, gifts, and generosities do you think are appropriate? What improved efforts to educate consumers of open source software would be effective? Further still, what kind of culture do we want?
One that you can certainly do is to be one of the voices of positivity and gratitude.
If I enjoy or benefit from something someone has released into the world, I've started trying to send them an email of thanks.
Many times I've gotten responses back, and they are always really grateful for the support. As a hopeful creator with a small but growing following, I've gotten a few of these myself and they really are motivating.
I generally make it a point to never criticize anyone online, since they probably know everything they are doing wrong acutely well and don't need me to tell them again.
Python is currently adding a “thanks” command to their package installer pip. There are efforts to wire pip to monetary rewards. I believe that’s the right direction: identify where the rubber hits the road most of the time, and insert positivity and gratefulness.
This was actually an idea proposed by RMS probably 20 years ago, but I think he was talking about music. Essentially it's the busking model. The key is making that small donation extremely easy to give. And also to get big corporations to press that button.
It seems strange to me that you're so concerned with how we should try to be more respectful to Rich given the querulous and disdainful tone of his post.
I took what I see as a moderate position lightly criticizing his tone, but because you're going way farther than that and asserting that he can be as much of a jerk as he wants, let's address that argument.
I think it's nonsense. Rich is probably among the most brilliant software engineers on the planet but that has no bearing whatsoever on whether he needs to be polite and show human empathy and decency like everyone else does. You can be toxic and hostile and people will put up with it if you're useful enough (c.f. Linus) but we shouldn't be lining up, comment after comment after comment, to cheer that kind of behavior on.
Again, I don't think this is a big deal. I think that his rant is just a small indiscretion and we're all human, but I'm dismayed to see such an outpouring of support for exactly the position that you're putting forward. What I'm saying isn't "nauseating PC culture" as one GitHub commenter put it; it's just not being an asshole.
Well, he and other 147 people, according to the GH contributors page. Though, granted, none with anywhere near the same level of contributions to the core.
> As a user of something open source you are not thereby entitled to anything at all. You are not entitled to contribute. You are not entitled to features. You are not entitled to the attention of others. You are not entitled to having value attached to your complaints. You are not entitled to this explanation.
Thanks for being one of the few voices of humanity in this exchange. This whole situation just feels.. icky.. to me. I wish I knew what long term effects Rich's statement will have on the community, but I can't help but think that it will probably verge towards the opposite of embracing diverse viewpoints. That makes me quite sad.
Rich is very quick to escalate from “I feel X about action Y” to “you are Z”, where Z is negative.
Example, people are frustrated about how Rich runs his project. They are expressing how they feel about Rich’s actions, which is fair. Rich is under no obligation to change, but Rich’s response is to call people entitled. This is an attack against the person, not against the action, and it’s a chilling escalation.
The far more important and long-reaching gestures would be: expressions of thanks, and standing up for creators whenever unwarranted demands are made upon them.
Like "everyone can freely use and modify this, except the people listed in appendix C, who are specifically prohibited from using any part of this code for any purpose whatsoever".
If you get too shitty at the maintainers, you get added to the C-list, and get to take your shitty attitude somewhere else...
yeah, I get that. But in any other area of life, if someone is being a complete dick to you, then you can cut them out of your life. Why can't open source maintainer?
It’s a bad idea to get into pissing matches with shitty people. It’s bad for your mental health and it makes you look like a child. Ban toxic people from the mailing lists, I am all for that, but stop giving them drama and attention.
I think this also fits nicely with the backdoor thread posted earlier today. There is an immense amount of pressure and expectations put on folks who open-source things.
The other side of this is that open source projects are not entitled to users, or relevance. If they aspire to those things, then being responsive to their users and making something amazing that strangers want to use is part of the process.
Neither side has any particular obligation, but open source creates the most benefit when users and developers make an effort to be considerate towards each other.
I don't know why more people aren't pointing this out. It's almost as though people don't realize how much the value of Clojure comes from the community. Or aren't aware that many of the most helpful and constructive members of that community are burning out and leaving.
"At first, each community is defined by its potential. But as that potential is realized, the community begins to be defined by its compromises. That change is felt most keenly by the people who were there first, who remember what it was like when anything seemed possible. They feel fenced in and so they move on, in search of their golden city."
I've yet to see a non harmonious relationship between constructive and helpful community members and the core team.
I'm also not that sure the community contributes as much as you think. I use Clojure for work, and 95% of all value is from the core team only. I'm not trying to say the community is bad, I'm part of it, mostly trying to point out that it actually is quite disproportionate in relation to the core team, and I don't think we can criticize them until we (the community) actually step up and start being a lot more helpful and constructive.
As a serious user of Clojure, I just want to point out that one of my favorite thing about Clojure is the consideration that the core team has for its users.
I don't think this gist is targeted at users, but at other contributors.
As a user, Clojure is one of the best community I've ever been in. Where else do you get someone from the core team answering your questions in less than 24h ?
Design choices are well explained, the ticket process is well detailed on the Jira, the conj each year announce what to expect in the new version, and everyone is polite, inclusive and friendly to newcomers and beginners alike.
I've been engaged for the past 3 years. Maybe I'm just lucky, but I've always received very quick answers to questions. I've had inferior support from paid offerings in comparison to be honest.
Imagine belonging to an expert, seasoned team that masters a given technique. Literally the worldwide top 1% for that technique works under your roof.
You don't take feature development lightly: each feature will be discussed and polished patiently within your team. And then you release it, for free.
Then semi-random people from the internet want to continue the discussions that were settled privately long ago, while also demonstrating this entitlement.
I guess that can be a maddening, constant stream of noise. One that cannot be dismissed harshly - you may be an expert, but definitely don't want to scare people off.
Kudos to the Clojure core team for resisting the stream in a classy, illuminating manner.
> Imagine belonging to an expert, seasoned team that masters a given technique. Literally the worldwide top 1% for that technique works under your roof.
That would worry me immensely. What sorts of things are we not realizing because we're not exposed to other ways of thinking? What sort of talent are we not training up because we don't know how to recognize it? And what do we do when some of the people under our roof retire?
Have you ever hired someone who worked at Google? They're quite probably in the worldwide top 1% for software engineering talent, and still they come out of Google expecting everything to work in a Google way. And conversely there are folks at my company - skilled software engineers - who I wish would go work at Google for at least a few months, because they've been here for probably ten years and while they're very good they've never seen how other people do things. They're skilled, but they simply have not had opportunities to learn deeply from the outside world, and in a field moving as fast as software, no single organization can keep up.
This is why open source exists in the first place. Whether or not you think there's an ethical imperative to share software, the whole idea of open source is that different companies can share source code to produce better results than in-house development and buying licenses to closed-source software would achieve. At some point, if you're on an expert team that works under one roof, you're going to stop being the experts in the thing, because the other 99% of people interested in the subject can all learn from each other, can try the things you dismissed privately long ago, can experiment at scales you simply couldn't imagine.
yeah, thats important, but its also not whats happening here. This is an argument between people who've contributed a great deal to clojure and clojures ultimate authority. Which is completely different then entitled randos drive-by commenting and demanding accommodation.
I haven't used Clojure much but what I hear is mostly great. And I love this rant, its always refreshing when people speak their minds.
But.... Rich is pushing things a little too far I believe.
On the front page of the Clojure web site, under the section 'Rationale", his very first 6 words are:
> "Customers and stakeholders have substantial investments [...]"
Those words do not sit well with (from the rant):
> "[..] you are not thereby entitled to anything at all. You are not entitled to contribute. You are not entitled to features. You are not entitled to the attention of others. You are not entitled to having value attached to your complaints. You are not entitled to this explanation."
I get it, Rich is making a point, and its a fair and unarguable one - if he indeed has no loyalty or feeling whatsoever towards said Customers and Stakeholders.
But in the real world, we want our work to be valued by others, and I'll bet that the stewards of Clojure feel just the same and maybe shudder just a little.
Rich Hickey stands for good design. That means saying "no" to a lot if ideas that are good, but not part of the vision, and it means not running experiments on your users in the main releases. Whether he reaches that ideal, I dunno, but he lays out the vision pretty clearly when he speaks. It isn't the only way, but it is Clojure's way.
When he talks about customers and stakeholders, he is talking about people who have bought in to that design. It is very easy to support his position here. Rich knows exactly how he wants to program and the man is a visionary of data-driven programming and thinking. If you don't like that vision, maybe don't use Clojure and find a different lisp.
Great design is a very foreign idea to a lot of mainstream software developers - most of them, sooner or later, go for the "big rewrite" because they didn't get the design right to start with. Things like Python 2 -> 3 spring to mind (breaking changes to print! whoever thought that was a good idea didn't respect the language users). With that rational, he is promising not to do exactly what the Python people did.
There is a big difference between design and bug fixes. There are many small tickets with bug fixes already written that have not been merged into Clojure citing Rich’s time. Sometimes months or years go by, even when the Jira thread includes supporting comments from Alex Miller at Cognitect. Small fixes that improve the language without altering its design, making core functions more stable with edges cases, and they never make it into the language.
> Something that is often very hard to understand (it took me years to do so). Is that maintaining a language is insanely hard. Everything has a cost. Let me give a good example: A few years back someone submitted a patch that improved the error messages in Clojure. Worked great, just a single extra "if" and a message. It was committed to master.
Then people's code got way slower. Why? Well this was a often used function and that single if blew the JVM inline budget causing that function to never be inlined. And that improvement had to he yanked out.
It's caveat emptor, even when you pay $0. When you choose an open source tool or library for your project, or even a closed source one, you need to evaluate what support / bug fixes / modifications / enhancements you will get in the future and if it will meet your needs. Are you prepared to fork or workaround things where it doesn't meet your needs. Or is it better to choose another library or tool?
I kind of wish people complaining about Clojure's development process (and of other open source projects) would just create a fork and implement their own ideas.
This way, everyone could benefit from the experimentation and likely some of their ideas would get rolled into the root project once they have proven themselves.
They mostly don't matter to users, because most forks fizzle out due to lack of interest, unless there's a really good reason for the fork. If the original maintainers aren't doing something weird like re-licensing under a more restrictive license or closing off development and refusing good patches from the community, it's very unlikely a fork will gain enough traction to end up on the radar of most users.
We've had a few forks of our projects over the years...most often, there's just one initial commit with a few minor changes and some big words about how cool it'll be when the community can steer the ship...and, then nothing, forever. The thing about forking a big project is that it takes a lot of time and effort to make it better, or even significantly different, from the project you're forking. "Do not fork lightly" is good advice, but mostly because it's gonna be a waste of time in most cases.
This is why I've never worried about anyone stealing my ideas or code. The set of people who could both actually have the ability to pull off forking something and running the project, and have the motivation to see it through, is so vanishingly small as to be non-existent.
It has actually worked out pretty well in the case of Typelevel Scala. Users are free to compile using mainline Scala while using libraries that are built in Typelevel Scala. In most cases, this isn't even exposed to the user.
> To be honest, I could use that money in my retirement account, having depleted it to make Clojure in the first place.
A perfect example of the significant cost and personal risks people take on for the benefit of producing open source. I'm as glad Rich is saying this as I am he made Clojure (and open sourced it!) in the first place.
I run a few OSS projects, among which one with 10k+ github stars that has a decent size community. While I recognize my own personality in Rich's post ("if you don't like my direction.. there's the door") for some reason I ended up running this project with the attitude that everyone I am interacting with their time, insights, and needs are just as important as mine. It's been very refreshing. It makes people very eager to contribute, and there's close to 0 hostile behavior in the community. It really works magic.
I have no doubt that Rich's time and his direction of Clojure are endlessly more important than the average community member, as a fact. But you CAN'T communicate this way! Interacting with someone where before you start there is the assumption that someone is way more important cannot result in a good interaction. Even if it is a fact, even if both people involved know it, you will be much better off if you act like it doesn't exist for the purpose of communication.
Of course, time is limited, but I find there is an art to giving short reactions that are still respectful in this way. And it is not like Cognitect entirely does NOT want there to be community interaction (like Rich himself says), so it is just a question of optimizing these interactions.
It still boggles me that Jira tickets with small bug fixes to real problems confirmed by other members of Cognitect have never been merged, due to Rich’s time. Simple fixes to core functions that make the language more stable for edge cases without breaking design or backwards compatibility. Fixes that the Jira threads reveal others at Cognitect support patching and for which patches have already been written. Tiny fixes with little code involved. I understand being conservative on new features but isn’t it in everyone’s interest, including Rich and Cognitect’s, to fix actual bugs?
The answer tends to be that if the bug doesn’t affect Rich personally then it does not get attention. That doesn’t seem healthy for the language.
We actually never got our bugs solved. My particular favorite was CLJ-1741, which made reloading code with Cursive basically not work in our code base. Opened in 2015, effectively abandoned to its fate in 2016.
Well, I mean, it's still open. I'm sure if it got more votes on it, it would be better prioritized. That said, I guess this is a good example of a possibly starving issue where the core team can't scale to address the most minor issues.
I see Github playing a big role in bringing about this situation. The collaboration model focuses on the "who" of software development and not the "what". It used to be people were concerned about making a piece of software that did something interesting. Now it's all about how many stars, forks and followers you can get. Github made it too easy to "collaborate" and now you see any number of non-developer interlopers pushing project owners around. There needs to be a new model that's not so focused on the social but is focused on the tech and just the tech.
He is correct that open source developers don't "owe" anyone anything. But this is kinda missing the point.
The point is that if you have a bad development process, people are going to have issues. And these issues are real.
Even though you have no "obligation" to solve these problems that you have created for other people, you shouldn't be surprised if people bring them up, or perhaps even fork the project with a bunch of other people who also have problems with you.
Sure, the community does not own your time, but neither do you own the community. A community is fully within it right to do something else with their time, or convince other people to contribute to a different project.
> Even though you have no "obligation" to solve these problems that you have created for other people...
Publishers of open source code don't create problems for other people. People who accept that code into their projects assume those problems for themselves.
If an open source package has bugs in the forest and nobody is around to install it...
> But kindly don't burn the community down on your way out, with self-serving proclamations
This is him complaining about what the community is doing. The community is free to do what it wants, and he is making some sort of statement as if he owns the community in some way, and therefore can decide what is or is not "burning it down".
Convincing other people to leave the closure community (IE, burning it down) is a perfectly reasonable thing to do if there really are problems with it.
Complaining about what the community is doing, is him making the same mistake that he is complaining about other people doing.
1) The problem is that not every company has the resources to maintain its own fork of the code base. Some of us are one man bands, work in quite small teams of less than 3 or 4 developers. This idea that people have the resources to maintain their own fork of the code is crazy.
2) Two it creates fragmentation. Fragmentation creates defects and incompatibilities.
As I gotten older I pretty much realised that unless it is backed by a professional company I am not using it. There has been consistent stream of fiasco, drama and general unprofessional bullshit in the realm of open source I am quite happy I've mostly stuck to doing the majority of my work with .NET and SQL Server.
(Downvoters: Did I read his essay incorrectly? The reddit post from 1 year ago and the github post today seem be the same theme of managing the community expectations of Cognitec.)
Rich put it well that Clojure is not closed, it is conservative. He made it to solve the problems he encountered in the industry, which were large multithreaded proprietary systems. It is a business first language (cognitect is a consultancy, after all). The fact that so many hobbyists like me ended up using it was kind of a happy accident.
These two audiences don't have completely opposed interests, but they do have different priorities. Businesses care about stability; they don't care much about whether the language accepts PRs on Github or conducts twitter polls. I accepted that a long time ago, and I'm still using it six years later.
>Broadly yes, but I'm guessing this one was sparked by this thread
Ok, I see the possible confusion. I wasn't trying to say they were related to the same event. I was trying to point out they were related themes.
When I read today's post, I had an immediate sense of déjà vu. No wonder, he used the word "entitlement" repeatedly in both posts a year apart. (Counted 11 times in today's post and 4 times in October 2017.) He also mentioned personal sacrifices of losing money on Clojure in both posts. (The "retirement money" in today's post and "$200k" in last year's post.)
I don't follow Clojure closely but the meta question/observation is that there seems to be a profoundly broken misunderstanding and recurring pattern of negative interaction between the Clojure community and Cognitec that causes Rich Hickey to express his frustration in way that other folks Ruby's Matz, Rust's Hoare, didn't have to express. (Maybe Hoare left years before the Rust community could turn on him and accuse Mozilla of holding back progress in the language (and therefore Rich's predicament is inevitable if one stays involved long enough) -- I dunno.)
Yes, different specific triggers but the same type of frustrated response. I thought they were over a year apart but you're saying the frustrations are unleashed every couple of months so that's news to me.
I think it's also true that Cognitect is invested in the direction of Clojure in a way that Matz's employer (Heroku), van Rossum's employer (Dropbox, before that Google), and Hoare's employer (Mozilla) are not. Cognitect is doing commercial support for Clojure, and sells the closed-source database Datomic. Heroku, Dropbox, Google, and Mozilla merely want to see Ruby/Python/Rust succeed. They're not consulting for / commercially supporting other people who use those languages, and while they desire to see their own use cases supported, the community understands they have no fundamental conflict of interest (which is often more important than whether they have a conflict of interest themselves).
In turn, it's in the interest of Heroku/Google/Dropbox/Mozilla to build a genuine free-software community around the language, to pass off as much important stuff to volunteers who seem like they're building good things, to let other people have a seat at the table for language design, to give a commit bit to people who work for other companies. As far as I can tell, that's not the case for Cognitect, which is why this post makes it sound like supporting the community is a thing done out of the goodness of Cognitect's heart, that the fact that less than 1% of Clojure users are Cognitect customers is bad, and that Hickey could just take the money into his retirement account. These other companies can't just take the money - they would lose money if the community dried up.
You're downvoted, but I think that's a bit unfair.
Graydon did leave pretty early, so there wasn't this kind of pressure yet, really. However, after he left, we moved to a "core team" model, which meant that a few people (I among them) were the decision makers for everything. This eventually lead to complaints and pressure, and we opened it up further from there, adding all the other teams.
I haven’t used Clojure much in the last two years, but this is the part I remember is most surprising, and completely congruent with what Rich describes. You hear about this thing, it is a Lisp, and you wonder if it might be some edgy thing, moving fast, breaking things, showing off this mighty power (that Paul Graham wrote about) of Lisp.
And it is a little bit of that; but it's also a lot more of an intentionally conservative, even boring, extremely practical tool for building real things in a concise manner. In this way it fits into the Java ecosystem well, alongside many other very boring, robust, proven, reliable chunks of code.
Much of my work today is in the Node/NPM/JS ecosystem; although that has its advantages also, some days I really miss the boring reliable conservatism of Java and Clojure!
I would argue that if you release an open source project, you do have a responsibility to communicate enough about your intentions that potential users can base their expectations accordingly.
That doesn't have to be at any particular level. But if a project is unmaintained... why not tell people? If you are sharing a project in case it's useful to someone but don't really intend to deal with any external bug reports or feature requests at all... why not just clearly advertise that?
Nope, you're not entitled to anything. A license is just a license. You're free to use the code. If the releaser gives you no communication about expectations, then it's your choice to use it or not. They're obligated to give you anything, not even the time of day. Enjoy your free code, or don't.
Although there is of course no warranty, I think it's fair that when projects have marketing websites saying how great they are and encouraging widespread use, users can complain when the software isn't fit for use.
If you're going to be strict about how you don't owe anyone anything, it might be a good idea not to undermine that message in your marketing. Better to tell people all the reasons why they shouldn't use your code. Not for production! There may be bugs that you have to fix yourself!
And then work with developers who don't scare easily.
This post is absolutely correct. All your entitled to (if anything) is the code, as is.
You're not entitled to:
* Community engagement
* Bug fixes
* Timely pull requests
* Anything else
You get the code as it has been released. Whatever you do with it is up to you. The finished product you build using the code you have found is your responsibility and yours alone.
> Morale erosion amongst creators is a real thing.
It reminds me of a project called aurman [1] (a great AUR-Client for Arch Linux). Due to the 'feedback' from the community, the main author went from loving to work on his project to hating it. In the end, he stopped the public development to protect himself from the negativity.
I think there’s a time though when an open source project becomes so dominant in its field, that alternatives become few or untenable. In these cases were all at the mercy of the market for having consolidated on a set of choices. The mindshare around the project gives maintainers a tremendous amount of power over others.
Many mainstream projects fit into this. It’s not feasible from a business perspective to get to fork Linux or MySQL. There’s alternatives, but if they don’t work not everyone can spend startup funding to build a NoSQL database.
In these cases committers have a tremendous amount of power and often get disconnected from practitioners.
Android runs on billions of devices and is a fork of Linux. There's two or three commercial forks of MySQL, I think Percona started before Sun bought MySQL, but I can't remember for sure anymore.
Few small companies can maintain a full OS, regardless of the open source alternatives. Yet FreeBSD, OpenBSD and SmartOS are all still living projects, and none have a Google behind them.
People are inherently selfish. Everyone is looking to better their own self-interests, seek validation, and seek attention in life. A community - any community - is made entirely of these people.
An effective leader is one who can play to the strength of this fact rather than fighting it. You have thousands of people willing to spend their time for you. How can you make their interests align with your own? How can you convince them that your self-interest is their self-interest?
Funny, but I don't think calling people entitled is the answer to this.
I maintain a few open source projects that many developers use (along with many more projects that no one uses) and I get like one PR a month. It seems like some developer’s entire workflows depend on some of the tools and libs I maintain, but I don’t even use the damn things myself.
That seems like the perfect case for self interest: make this thing you use all the time work better for you. The code is usually fairly clean and the contribution process documented. And yet all the help wanted issues just sit there.
How have other maintainers been able to encourage more valuable community contributions?
Could it be that people who use your OSS think you have an obligation to them, because you marketed your software in a nice and pretty gift wrap package (eg. web page) and they chose yours over and alternative (ie chose to invest their time and effort on it)? They chose to "fall" for your marketing over that of another project.
Maybe they feel that by choosing your software over an alternative, they're also helping you (since it's your project after all) and they atypically expect some things of you?
P.S. I'm not taking sides. This is just a shower thought.
Although I appreaciate almost all opinion articles and videos posted by Rich, what I read here is that Rich seems to see his project about himself which fits his previous behave as Clojure's Dictator For Life. In other words, he could never remove himself from the equation or make clojure an independent long standing self directed project.
In general terms of OS project, I think the first premise is already flawed. What if there were open source projects meant to satisfy their users or public? Or just iwth very different goals than yours? Do you even think that software is just finished when it is released? that fanbase should be allowed? What if Rich itself is the main bottle neck for his own masterpiece?
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.
Now, he should answer this own questions and make his own logic for his own project. I personally always saw open source as complex as a society is; as complex as an MMO game game can be. (including actors such fanbase, devs, sponsors, investors), etc.
It's painful how many people don't seem to think this way. If you've ever contributed a patch to an open source project, do you think you should be obligated to maintain this patch for the foreseeable future? If the answer to that is 'no,' then why would a greater contribution, such as an entire project, be held to such obligations? It's disappointing.
A decade ago I found Rich's way of communication tough to swallow and borderline abusive, but re-examining it with the acceptance the years of using probably the most expressive and versatile language on the planet I find it refreshingly clear and to the point. And he's absolutely right of course, his time is just that, his time.
Arguably the best and most important thing an open source author can do is engineering their code the way as easy to understand and extend (this doesn't mean an over-engineered architecture, quite the opposite) as possible so whoever wants something particular could really easily add/change it with an extension or by forking and editing the core code. This done you can really legitimately direct those asking for what you don't feel like doing to do it themselves. Another great idea, IMHO, is hosting issue tracking on GitHub and making it the only accepted channel for feature requests and bug reports.
Making github the only accepted channel for anything is hardly a great idea. Perhaps if you used "an additional" instead of "the only" in that sentence...
I believe this way people are more likely to be reasonably self-moderating and specific and less likely to engage in personally emotional argument with you than if you use e-mail. It will also give people convenience of filing a bug/suggestion without having to register on yet another bug tracker given they already have a GitHib account (who hasn't?). Needless to say using a single bug tracking system and input channel is much more convenient for everybody than if there were many.
> We take some of what we earn, money that could e.g. go into our retirement savings and instead use it to hire people to work on Clojure and community outreach, some full-time. To be honest, I could use that money in my retirement account, having depleted it to make Clojure in the first place. But I love working with the team on Clojure, and am proud of the work we do.
... and then this...
> Open source is a no-strings-attached gift, and all participants should recognize it as such.
Is control of the closure project part of lead dev's business model, and the part about dipping into retirement just an "open-washing" of "I decided to start a business?"
Otherwise this sounds like an extremely unhealthy and unwise "gift" on which to spend one's retirement savings.
Aren't gifts _usually_ at the giver's expense? Anything else is a transaction, surely.
I think the only point being made there was that this gift is expensive but he's happy to give it. The way I read it, he's happy to give out free iPhones, but asking/demanding a battery-charging case and extra Lightning cable on top might be pushing his generosity.
> Aren't gifts _usually_ at the giver's expense? Anything else is a transaction, surely.
Usually with open source the "gift" is the author/maintainer's time. "Gift" in quotes because there is usually immense pleasure in creating and controlling a project.
If the author/maintainer is ranting about the sacrifices they make for the project, that usually means something has broken in project development process. And I've never heard of another project where the author dipped into their retirement savings and built up less savings than they should have to support their authorship of a project. That's a problem that should never happen, not ammunition for rationalizing the pecking in a project.
The iPhone example doesn't work. I can't send a patch to ostensibly improve the hardware (or even software) of an iPhone. The audience the author was addressing was other developers presumably complaining about low patch acceptance and long wait times. In that light, process conservatism and generally low patch quality are persuasive arguments for the status quo. "I'm sinking my retirement into this" and "community-driven development is a myth" are not.
> there is usually immense pleasure in creating and controlling a project
I think this is the part of a larger myth against which the writer rallies.
The joy is not in maintenance and control. The joy is in working with like-minded peers who share a vision, the joy is in designing and implementing an outcome that does what one wants it to do, the joy is in being able to share it.
The mundane activities associated with that are not joy. That's just work, not pleasure. Those aspects of project management are means to an end, not the actual end.
> I can't send a patch to ostensibly improve the hardware (or even software) of an iPhone. [...] developers presumably complaining about low patch acceptance and long wait times
Rich said that the sorts of patches people were submitting were of low quality and didn't fit the overall project vision. Then people were getting upset because their amazing patches weren't being accepted there and then. Frankly, that's not a community I'd want to foster nor be in charge of. Nobody should want that.
I don't see any conflict at all with a statement along the lines "I am the leader of this project, this is my baby, and I have sunk a lot of my time and resources into it" next to "I'm not accepting your pull requests and patches willy-nilly just because you complain a lot".
If I'm forced at work to work with mediocre FOSS stack without support culture (even for paid tiers), it is about me. I'm not choosing to work with a subpar farce of a technology like npm, it's forced upon me.
I'm not a user of Clojure, but I'm a user of other FOSS tools (Docker) for which I've had complaints.
Though I have potential issues here, I think it is important that this be said. It highlights missed expectations. This open source thing is a weird new(ish) world, and we need to be on the same page. It's been a few decades, but perhaps we haven't quite adjusted yet. Or maybe this hippie thing actually doesn't work, which would be a real shame.
The fact is that we rely on it. And I think that this really is an alternate mode of creation. I could be wrong but I don't think the idea of "community development" is something that was recently made up. It's part of the Free Software ethos. Perhaps what is new here is a notion that there not be a party at the top of each fork who has ultimate responsibility.
A pure gift, take it or leave it, no strings attached in either direction, is fine, and should be appreciated. But it's useless to users who need to rely on what you've produced. If the project is not subject to the demands of its users (which includes contributors, to the extent that they are users with demands that they are willing to fulfil themselves) then it's got a serious disadvantage over commercial software without a free distribution model. It's not akin to a serious tool for sale. And _if that doesn't meet expectations_, people are within reason to push back.
The other side of it is that there have to be limits, of course. There has to be respect for the producer, their time, their preferred mode of management, the limit of the scope of the project, etc. There have to be judgement calls made, just like commercial software without a free distribution model, as to what does and doesn't make it into the project. For all these reasons I can see that it's important that a producer pushed back here.
But if the producer doesn't voluntarily take on some level of responsibility as part of running the project, whatever the terms may be, then at the end of the day the project can't be relied on within the economy. This is not a demand on the author of this post. He is entitled to treating Clojure under whatever terms he wants. But somebody has to, for it to work in our system.
I think the solution is just better messaging of expectations. What this project is. What expectations should you have as a user. What expectations should you have as a contributor. Now we can all look at it as a reference point, and decide: Do we want to rely on this? Do we want to spend our time working on this? Do we have a basis for complaint?
Really, this is the same set of questions that are answered in any business arrangement. Perhaps there needs to be a SOCIAL_CONTRACT file next to LICENSE, README, etc.
I think if you are doing an excellent job with your project, noone has time for you[dev] , as they are too busy enjoying your project.
its like when granpa tries to get in on the basement gamefest with the kids.
let them play, your best contribution is to make more toys for them to play with and let come to you and ask for more.
It gets pretty tiring on HN/reddit to watch people demand so much shit for free, namely other people's time. If you've ever run a project with users (most people haven't), you've experienced these demands first-hand.
It's nice to read these sorts of posts when it's getting you down.
For me it was the recent outrage at Elm's creator. Random people on HN/reddit basically acting like they were some disgruntled paying customer. You can see a common thread with Rich's defense of Clojure.
Would you mind giving a bit more context/link to the HN discussion(s) about Elm's creator? I've seen the JS event-stream kerfuffle stuff posted all over the internet today, but I havn't heard about the Elm thing.
Elm is a very locked down ecosystem, heavily influenced by a single lead developer (Evan Czaplicki) with a very small team of assistants. Development is slow, and focused heavily on what Evan thinks is best; features he doesn't use or doesn't think are working out can (and have) been removed. If he doesn't think a bug is critical, it will be ignored. If Evan decides that the way a chunk of the Elm ecosystem works isn't really in line with his vision, then he'll rewrite it. If that's a breaking change, so be it. If maybe Elm goes a release or two with an important feature not working because Evan is halfway through rethinking something, then sure, that's a thing that happens. The Elm dev team is small, their resources are limited, and they're focused on moving the project forward.
Some people see this and go "okay, I'm fine with this, I like Evan's vision and I want to see where this is going"; many of them use Elm in production and accept the occasional bumps in the road.
Others are interested, and happy to watch from afar, but are waiting for Elm to hit some form of 1.0 release or otherwise announce that it's ready to be used in production before making the jump. (I'm in this camp; Elm is clearly not suitable for me today, and that's fine!)
And some take the entire thing as a personal affront. Entitlement is an issue across all of open source, but Elm has some characteristics that makes it especially prone to driving a certain type of user wild. How dare Evan change Elm internals in a way that breaks the way they were using Elm?
Yeah, Rich is obviously right. Concerning Clojure, or any Lisp variant for that matter, I came to realize that the cost of the unusual prefix notation -- which does cause inconvenience to people trained on using infix -- needs to be offset by the usefulness of defmacro, i.e. the possibility of using macros. Paul Graham insists that it is surely worth it, but unfortunately, he does not show convincing examples. So, I keep sitting on the fence. I am ready to be convinced, though, with compelling examples of a problem that I cannot possibly solve with defun and for which I would need defmacro.
The parenthesized prefix notation is advantageous because it is unambiguous and easy to format. People trained on infix still make mistakes due to associativity and precedence: mistakes in understanding an expression and in writing the correct expression which matches their intent. Their skill does not translate into unfamiliar languages that have unfamiliar operators with unfamiliar precedence and associativity rules.
The user of a Lisp benefits from the development which has gone into the language/implementation. That development is lubricated by the structure of the code. The Lisp programmer does not only write new macros, but uses existing ones, either in the language/implementation or third party libraries.
There is no problem you cannot possibly solve with defun (plus escape hatches to access any aspect of the host environment), because defun gives you access to a Turing -complete computation model.
This is simply not a genuinely honest way to evaluate tools. Gee, I'm not convinced that there is a text editing problem I can't possibly solve with ed if I bash at the keyboard long enough; so for now I will keep sitting on the fence.
possibly isn't easily, efficiently, maintainably, and so on.
I think that programmers would generally be willing to overcome the inconvenience of the unusual notation, if the advantage of using defmacro was obvious from good examples to which they could, at least, relate. This question was also asked on stackoverflow: https://stackoverflow.com/questions/267862/what-makes-lisp-m.... My opinion is that the examples in the answers are neither obvious nor compelling. Hence, I am still waiting for better examples.
I'm guessing that this is a response to the current trend towards Codes of Conduct, which are best understood as part of the Long March through the Institutions, a politicization of things that aren't inherently political.
Although, there's something to be said for some potential overlap here. A lot of Codes of Conducts are basically being demanded by people who're not a part of the project.
Rich's point stands up well in response to that sort of thing: if you want it so damn much, fork it, do it yourself, and leave me to do what I do best.
That's the true beauty of open source, that you can just fork, do it yourself, and there we are. If your project is so much better than the original, people will flock to it. If not, well, at least you could still do what you did.
If I make infinite bread loaves and you're allowed take some loaves and _also_ see the recipe, that is quite clearly sharing by every definition out there.
We've banned this account for repeatedly breaking the site guidelines and ignoring our requests to stop. That's not ok, even if some other account was wrong and/or broke the site guidelines as well.
Rich Hickey needs to stop poking people in the eye with a stick.
> 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.
This could be handled much more diplomatically. What he's saying here is "fuck you and your needs". Opportunity cost waits for nobody, but taking a second to not provoke people is a good idea.
> We at Cognitect have to show up to work, every day, to make a living. We get no royalties of any kind from Clojure.
Ditto for the people who wrote open source libraries, some that are critical for Clojure's adoption. In fact they typically did this after working a 9-5, rather than during it.
> To be honest, I could use that money in my retirement account, having depleted it to make Clojure in the first place.
"Look how much I've suffered for you!" is about as effective for leadership as it is for parenting.
> But kindly don't burn the community down on your way out, with self-serving proclamations.
That's a nice "fuck you" to frustrated developers. "Shut up with your complaints and go away" is a bad community management technique.
What's next, people who sell cars aren't responsible for making sure they're safe? People who sell food aren't responsible for whether it gives people food poisoning?
If you release a product then at the minimum it's your responsibility to make sure it's not going to harm others. If you can't do this then you shouldn't be releasing open source software.
Adding a disclaimer at the bottom doesn't absolve you of gross negligence.
"Sell" is a pretty important word there. There are laws and regulations for those, and neither comes with an explicit license saying something like "disclaims all warranties and conditions, express and implied, including warranties or conditions of title and non-infringement, and implied warranties or conditions of merchantability and fitness for a particular purpose."
> neither comes with an explicit license saying something like "disclaims all warranties and conditions, express and implied, including warranties or conditions of title and non-infringement, and implied warranties or conditions of merchantability and fitness for a particular purpose."
Because they obviously would be not legally binding. Again, you can't absolve yourself of gross negligence any more than you can sell yourself into slavery. And legally speaking, selling something almost always includes giving that thing away for free. (Except for in a few cases where gifts are specifically exempted, like for some low-level drug crimes at the state level.)
Companies don't care about making products safe until government steps in and forces them to. Unsafe food was not "next", it was the norm until Upton Sinclair wrote The Jungle. Unsafe cars are not "next", they were the norm; seatbelts were first recommended by a surgeon in 1930 who went on to form the Automobile Safety League of America, they weren't mandatory until at least 30 years later with seat belt legislation [1], or airbags legislation in 1998 [2].
Remember .. cigarettes? Arsenic Wallpaper and cloth[3]? Radium cosmetics [4]? Toasty warm Radium blankets[5]? Shoe fitting x-ray fluouroscopes[6]? Lead water pipes[7]? Sugar? Guns? non-fire resistant household furniture? Dinitrophenol[8]? Asbestos? Leaded petrol? CFCs? Unsafe buildings? Bisphenol-A? BSE related beef? 3D printers and their carcinogenic particle side effects[9]? Trans fats[10]?
and then why we have things like the CE marking safety standard in Europe. On and on, products are harmful by default until government steps in and forces manufacturers to make them safe(r). The free market cares about profit, not people.
What's next, people who make products are responsible for making them safe?
While the message is partially kind of correct, the delivery lacks everything that's humane.
> 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.
If this is the case, why open source or publish it in the first place? If you want people to read the code, but not interact with you, why not write that into the license? Why not use something like CC-SA?
> As a user of something open source you are not thereby entitled to anything at all. You are not entitled to contribute. You are not entitled to features. You are not entitled to the attention of others. You are not entitled to having value attached to your complaints. You are not entitled to this explanation.
Looking at that last sentence, then, why not STFU, Mr. Hickey? Assuming the "users" are Clojure programmers, if they're entitled merely to nil, why bother with this angsty rant?
> Open source is a licensing and delivery mechanism, period. It means you get the source for software and the right to use and modify it. All social impositions associated with it, including the idea of 'community-driven-development' are part of a recently-invented mythology with little basis in how things actually work, a mythology that embodies, cult-like, both a lack of support for diversity in the ways things can work and a pervasive sense of communal entitlement.
This is completely wrong. The reason we have open source in the first place is years long, decades long, determined community effort. Mr. Hickey is not entitled to change the definition of F/OSS.
FOSS is the mantra of a particular community-oriented software-development zeitgeist, where things are developed by a community, without a project maintainership per se—i.e. where "the project" refers to whatever the most active fork of the project is, rather than to the project as maintained by some particular BDFL.
FOSS projects are usually maintained under the aegis of one or more software foundations, like GNU or the ASF.
"Open source", on the other hand, means exactly what it says. Microsoft does Open Source. Apple does Open Source. Oracle does Open Source. It means exactly as little as the image conjured in your head by that list.
It's not that simple. Open source projects, including Clojure, benefit from the community through bug reports, documentation, free user support, articles, etc.
To make it as simple as you suggest, there should be a code repository and nothing more. I don't think that's the case in the majority of open source projects or even what Clojure desires.
That being said, if you're not contributing back to a project (in any sensible way, not just code) maybe you should tone down your demands. I completely sympathise with author but things are a bit more complex in reality. Ignoring the benefits of these interactions/contributions is not fair to the rest of the community that is contributing. Maybe the author does that feel that's currently enough? I can totally relate.
FOSS is just "free and open source software" - a catch-all for both camps to avoid offending anyone. It doesn't imply any particular development methodology or project maintainership.
I do not think it's fair or correct to confine Open Source to that definition the last paragraphy of your comment implies. It may only be a subset of Open source. ASF itself defines what it does as Open Source.
What's described in this rant is basically "Source Available". Open Source means more than that, per ASF, per OSI, and per many who publish software under non copyleft licenses.
> If this is the case, why open source or publish it in the first place? If you want people to read the code, but not interact with you, why not write that into the license?
Because there's a difference between 'can' and 'must'. It's great when people use my OSS work, give feedback, and even file bugs. What's not great is when people adopt the position that they're entitled to a fix right now (or ever), or that they're entitled to new features or design consideration for their minority use case. In summary, strawmanning someone else's argument is bad, and you should feel bad.
> [W]hy bother with this angsty rant?
Managing large OSS projects is about doing things at scale, like answering a question exhaustively once, in one place, so you can refer back to it instead of having to explain variations of it repeatedly, ad infinitum. As far as 'angsty', maybe start with a little humility: check your own biases before reading an attitude into someone else's message.
> This is completely wrong.
Nope, you are. Both in the technical/legal sense and the historical sense. Recommended reading: The Cathedral and the Bazaar.
Please keep nasty internet tropes like that one way, far away from Hacker News. If you'd review the guidelines and follow them from now on, we'd appreciate it.
So this is not some grieving random person from crowd - Chas is a person whose libraries and contributions I value tremendously and he certainly made LOTS of contributions to clojure OSS landscape for free and out of his good will as well. So ultimately this feels like your parents are arguing (which is never a good thing) - you like them both and you just want the arguing to stop and you just want everybody to live together in harmony. But here you go, Chas has moved away from clojure now. And I have to say I am very sorry to see him go.