(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.
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 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.
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!
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 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?
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.
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.
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.
> 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.
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.
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.
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.
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.
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.
>> Cognitect does not make money from Clojure. Period.
But it makes its money because it is the company of the creator of Clojure. AFAIK the company was started after Clojure gained traction. That means they are well compensated, that's as good as money, IMO.
Reading the original post and this, I don't think Rich Hickey is a good citizen of the F/OSS community. F/OSS is not about cost. It's about sharing.
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.
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.
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.
> 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")
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.
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.
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.
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.
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.
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.
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.
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 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.
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.
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.
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?
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 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.
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.
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?
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.
> 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.
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.
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.
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.
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.
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 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.
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.
> 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.
> 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".
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.
290 comments
[ 2.9 ms ] story [ 260 ms ] thread(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.
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.
Yes, this is the case. (As far as I can tell.)
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.
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.
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!
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?
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.> 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!
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.
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?
> 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.
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.
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.
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.
> 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.
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.
https://news.ycombinator.com/newsguidelines.html
https://news.ycombinator.com/newsguidelines.html
Associated Reddit thread: https://www.reddit.com/r/Clojure/comments/a0lalh/timothy_and...
https://news.ycombinator.com/item?id=18534392
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.
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.
Forks are not particularly fun from the user's standpoint.
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.
But it makes its money because it is the company of the creator of Clojure. AFAIK the company was started after Clojure gained traction. That means they are well compensated, that's as good as money, IMO.
Reading the original post and this, I don't think Rich Hickey is a good citizen of the F/OSS community. F/OSS is not about cost. It's about sharing.
You're a horrible citizen of the fantasy world where you give me things for free. That's some Kennedy inaugural address shit right there.
Please don't create HN accounts to do that with.
You however don't get to influence _my_ recipe.
We detached this subthread from https://news.ycombinator.com/item?id=18538285 and marked it off-topic.
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.
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...
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.
> 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.
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.
>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.
- Game developers
- Authors of popular novels that have yet to finish ("GRRM is not your bitch")
- Star Wars
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.
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.
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.
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.
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.
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.
Under US law, to be specific.
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.
https://www.gnu.org/philosophy/selling.en.html
https://community.ardour.org/download_form
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.
p.s. Was gonna ask "Which Carnegie?" but Google says Dale.
edit: Nice to see my work is making some impact. :-)
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.
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.
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.
- 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.
"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."
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.
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. :-)
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.
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.
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.
...I agree with his point 100%, and it's certainly relevant to other communities.
https://news.ycombinator.com/item?id=18538267
https://news.ycombinator.com/item?id=18538298
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.
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.
> 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.
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?
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.
> 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.
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.
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 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.
So, yeah, your comments are approaching "nauseating PC culture" because you can't read something like the original without being offended some how.
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...
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.
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.
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.
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'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 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 since abandoned Clojure. I didn’t trust the core team anymore.
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.
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.
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.
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".