(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.)
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.
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.
Associated Reddit thread: https://www.reddit.com/r/Clojure/comments/a0lalh/timothy_and...
> 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.
The best conclusion :)
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.
> What if Rich itself is the main bottle neck for his own masterpiece?
Then whoever thinks would do it better could just fork it and call it 'klosure' for sure!
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.
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.
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.
>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.
Forks are not particularly fun from the user's standpoint.
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...
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.
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.
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.
I witnessed one such event recently, and I feel pretty confident in saying that person was just having a bad day. Or bad moment, whatever.
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?
...I agree with his point 100%, and it's certainly relevant to other communities.
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.
> 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.
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.
- Game developers
- Authors of popular novels that have yet to finish ("GRRM is not your bitch")
- Star Wars
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.
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.
> start with a little humility
> Recommended reading
Good god. I just remember why I stopped participating in this place.
Please read that book you yourself first before name dropping it.
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.
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.
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.
Perhaps even, the more productive you are, the more enemies you will make.
People who are particularly unproductive tend to think that the world owes them something.
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.
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 positive way to interpret this is to recognize that fans are passionate and want the project to succeed and fulfill all their dreams.
But reality is a harsh mistress and not all dreams will be realized.
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 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.
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.
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.
Yes, this is the case. (As far as I can tell.)
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.
Thank you, Rich.
... 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.
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.
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.
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.
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.
> Open source is a no-strings-attached gift
> 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.
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.
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?
The free software movement, however, says things like this (from https://www.debian.org/social_contract ):
Our priorities are our users and free software.
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?
- Twitch streamers
- songwriters
- composers
- screenwriters
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.
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.
[1] https://www.copyright.gov/title17/92chap1.html#107
Here's an old-ish article I like to link to, on Waxy.org, called "No Copyright Intended":
https://waxy.org/2011/12/no_copyright_intended/
> 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.
By all means, read the whole thing.
Here's a lawyer's take on it:
https://www.traverselegal.com/blog/can-derivative-works-be-c...
> 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.
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.
If you don't understand this, then you don't understand the open source movement. See https://opensource.org/osd-annotated for a basic primer.
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.)
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.
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.
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).
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.
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.
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.
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.
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."
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?
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.
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!
"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."
Well, defun is a macro: http://clhs.lisp.se/Body/m_defun.htm
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.
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.
Seriously? Are you suggesting On Lisp contains no convincing examples? It's what the whole book is about.
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.
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.
After yesterday's NPM fiasco sorry but it is your project. You should fix the problems or don't release it out in the world.
Linus cares a great deal, he just doesn’t want to be cornered as an FSF zealot.
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!").
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.
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.
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. :-)
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.
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.
Under US law, to be specific.
Seems to be an ego thing.
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?
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.
I'm not even mentioning the potential split in the community.
> 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.
Also see my response on the gist itself:
https://gist.github.com/richhickey/1563cddea1002958f96e7ba95...
Feel free to use my HN comment as an upvote/downvote proxy since gist doesn't support upthumbs/downthumbs on comments.
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?
[1] https://en.wikipedia.org/wiki/Seat_belt_legislation
[2] https://www.history.com/this-day-in-history/federal-legislat...
[3] https://hyperallergic.com/329747/death-by-wallpaper-alluring...
[4] https://www.atlasobscura.com/articles/objects-of-intrigue-lo...
[5] https://www.sciencephoto.com/media/364732/view/radium-blanke...
[6] https://gizmodo.com/the-insane-cancer-machines-that-used-to-...
[7] https://www.ncbi.nlm.nih.gov/pmc/articles/PMC2509614/
[8] https://www.theguardian.com/science/the-h-word/2014/feb/06/d...
[9] http://blog.ichibanelectronic.com/3d-printers/3d-printers-ca...
[10] https://en.wikipedia.org/wiki/Trans_fat#Public_response_and_...
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.
"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."
"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...)
"All social impositions associated with it, including the idea of 'community-driven-development' are part of a recently-invented mythology..."
Reminds me of Margaret Thatcher saying "There's nos such thing as society." https://www.theguardian.com/politics/2013/apr/08/margaret-th...
Now if only they can get someone to keep repeating it, it'll be true.
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.
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...
People are getting a bit entitled as to what an open source maintainer has to do for them.
p.s. Was gonna ask "Which Carnegie?" but Google says Dale.
edit: Nice to see my work is making some impact. :-)
Also how do you think about post launch updates to fix bugs? Those seem to be generally expected as well, now.
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
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.
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?
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.
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.
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.
Uh-oh. I hadn't been aware of this. Do you have a link, please? (Quick google didn't help much.)
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 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.
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.
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 feels like a non sequitur. Having a right to do something is completely orthogonal to whether you should do that thing.
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.
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.
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.
https://github.com/dominictarr/event-stream/issues/116
Edit: it attempts to steal crypto-currency; it doesn't mine it.
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.
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.
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.
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.
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 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.
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.
> 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.
Usually "treat others like you'd like to be treated" is a good heuristic. If not I'd encourage you to seek a therapist and start working on yourself.
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.
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.
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.
This is just fact. You can go read the license to learn more about this: https://opensource.org/licenses/eclipse-1.0.php
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.
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.
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.
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.
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.
If the users have interests like, "I want to stick this piece of code into my proprietary program", then those interests are not prioritized.
Side note: it appears gist links aren't stable? I think halgari had the same issue when trying to link to his response.
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".
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.
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.
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'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.
I think most of those fixes you mention are actually semantic altering and thus possibly backwards incompatible.
I don’t see a problem with talks that show code (to support whatever the talk is about) without giving it away.
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.
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".
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.
So, yeah, your comments are approaching "nauseating PC culture" because you can't read something like the original without being offended some how.
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.
> 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.
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.
Also, the fans cheer him on, which is gross.
I since abandoned Clojure. I didn’t trust the core team anymore.
"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."
Where do these people get off?