Though Rich is right, it pains me to read this because it is indicative of some disputes in the clojure community. I might be mistaken, but it seems that Rich is reacting to Chas Emericks' twitter post (https://twitter.com/cemerick/status/1067111260611850240).
In his comments he has stated: "Finally, from a practical perspective, my core-level contributions always came from some source of pressing need in an actual, present, needs-to-work project. If I know a problem isn't going to be triaged for months and solved for years, then I'm out."
So this is not some grieving random person from crowd - Chas is a person whose libraries and contributions I value tremendously and he certainly made LOTS of contributions to clojure OSS landscape for free and out of his good will as well.
So ultimately this feels like your parents are arguing (which is never a good thing) - you like them both and you just want the arguing to stop and you just want everybody to live together in harmony. But here you go, Chas has moved away from clojure now. And I have to say I am very sorry to see him go.
Rather than reply to any of the various downthread issues, just a few clarifications:
* I don't know exactly who Rich is responding to, but I can't imagine it's for rando users who drop off drive-by TODOs for maintainers. More likely IMO it's in response to a number of people who have contributed significantly to clojure itself and to supporting projects and resources that have spoken up in recent times with various critiques.
* I'm super uncomfortable with any comparison to this kind of "dispute" as being anything like that between parents, etc., though I can see how some might think of it like that. Really, it's a disconnect of expectations and a lack of communication, which I'm glad has been resolved definitively.
* I do still use Clojure (though more via ClojureScript than otherwise), it's just not my primary rig anymore, and I'm strictly a user. The contribution process was a minor factor, not the driving rationale for my looking elsewhere; though, as I said in the posted tweets, I surely wouldn't have tarried so long if I knew earlier what I know now.
Thanks Chas for responding. Apologies for the parents metaphor if that made you feel uncomfortable - since at the time of my writing lots of comments on gist and HN were concurring with Rich and talking about "weeding out toxic personalities" I was just trying to come up with a metaphor that would offer a different perspective - that this is a type of disconnect that benefits no one and that there is no side that is clearly "good" or "bad" since all sides are needed for the whole ecosystem to work. Rich's statement was aimed at some core contributors (I am guessing now probably a bit more at Tim and less at your follow up tweet) and that worries me. Imho this situation is a lose-lose scenario: for Cognitect to lose contributors, for contributors to have spent hundreds/thousands of hours in vain and for anyone from clojure community who placed his bet on clojure and invested substantial time in learning/using/evangelizing it (affecting his/her market value in the process).
Anyway thanks for all the work on clojure! I am still using some of your clojure libraries!
Normal people who are using the software to get something done just maintain a local fork where they can fix fires as fast as they want, then treat upstreaming (if any) as a background task that is allowed to take the necessary time.
E.g. numerous GNU/Linux distros maintain local patches for numerous packages: kernel, gcc, glibc, ...
Some of these take years to get upstreamed, if at all.
The problem is that this process doesn't work so well for people who just want to leave their imprint on that project (that one and only official project, not their private fork).
Saying I'm not going to use this as my main tool if I can't have a more or less free reign in shaping the destiny of its one and only official version comes across as a bit of an infantile tantrum.
> "If I know a problem isn't going to be triaged for months and solved for years, then I'm out."
Some problems are easy, low hanging, do it yourself. I guess that's not the issue here, but it's worth mentioning as a lot of OSS projects don't cater to solving these. (Expose some little bit from an underlying lib, make something configurable, etc.) And there are the uh-oh we have to refactor half of our codebase to solve that one by the way totally valid problem. And that's usually not a one weekend "project", and it is understandable, that it might take years.
And at that point, I feel that the entitlement of "make this work for me, because there's a project that depends on it" is the problem. Sucks to be the guy who have chosen the wrong tool, even if it looked like the best tool. It happens all the time.
> As someone not in the know, Rich's post seems like an extremely aggressive and arrogant piece.
It seems that way? To me, it seems like a reasonable response to how many people treat any kind of volunteer-led effort.
For example, I help mod a fairly popular subreddit, r/cscareerquestions. Now, we don't have a problem with people suggesting changes to sub rules or have meta discussions and even complaints. No community is perfect, the mods certainly aren't, etc.
However, the vast majority of complaints are of the completely useless variety. They're the vague one-liners -- "this sub used to be good, and is now bad for generic reasons I will not elaborate on" -- that usually have no clear basis in reality, nor any practical solutions even to the extent they're true.
And when I try to earnestly engage with people who have the most upvoted complaints, 95%+ of the time, there's nothing there. Probably half the time they just don't respond, half the remaining time they just loose another snipe or parting shot before disappearing, and most of the rest is something in the set of {doesn't actually happen/no evidence; assumes everyone agrees with them; problem is actually well-diagnosed but the proposed solutions are laughably naive}. The number of complaints or suggestions that are meaningfully actionable is very, very low.
What I've found looking at other subs and ours, is that generic complaints about sub quality and mod team actions are a quick and easy way to upvotes, but it's rare for someone to actually be well-informed on the topic and have actually thought through the problem and solutions they suggest.
So when Rich says, "Did you know that most patches/issues have poor problem statements, no description of the plan (read my code!), no consideration of alternatives, no tests, no designs, and are ill-conceived and/or broken in some way?" that doesn't surprise me in the least. Even when people nominally want to contribute, they usually don't seem to try very hard. For me, it's gotten to the point where I'm writing a guide for subreddit criticism and suggestions to try and improve the quality of the complaining.
tl;dr - even when something is reasonably well run by volunteers, people love their low-effort gripes and snipes
> Though Rich is right, it pains me to read this because it is indicative of some disputes in the clojure community.
I am genuinely curious why you, or anyone else, would think he is right. I can see why people would agree or why he wants to do things a certain way, but to be right you have to have arguments backing up what you are saying. I don't see that in this post. Am I missing something?
> I am genuinely curious why you, or anyone else, would think he is right.
Because Rich has the rights to do what he wants with his time and money. (Like everybody else.) It is completely within his rights to establish his own governance and contribution model for his version of Clojure. At the very least, I don't see an argument why it's NOT within his rights to do so.
Of course, there are several corollaries. The first is that nobody is forced to use or contribute to Clojure. The second is that, given that Clojure is Free Software, it's possible for someone else to pick up the baton, make a fork, and run it their own way. (egcs and XEmacs both come to mind as examples where someone did this and it wound up improving the original.... so there _is_ precedent.)
I wouldn't feel terribly bad if someone made this fork, but I'm not going to do it myself. Unlike Rich, I'm not willing at the moment to make the personal sacrifices that'd be required to make this sort of contribution. Neither, apparently, is anyone else.
So Rich gets to make the rules. Because he (and Cognitect) have paid the dues. Whether that's good for Clojure in the long run remains to be seen. (But honestly, my semi-informed take on the ecosystem is that it needs library maintenance much more than it does core language improvements. The core language has been an excellent choice for many purposes for years.)
I mean, he is right about open-source only being a binding license for the source, and in this case, the Eclipse 1.0 license in no way entitle users too any kind of support, decision making authority, opinion, voice, or any other such thing.
That part of what Rich is saying is pretty much indisputable.
The second part, is related to what is best for Clojure. And the argument is simple, Rich says what is best for Clojure is a thorough review process of all changes to its core and standard libs, with a very high bar towards contributors and their contribution. His argument is that this has worked so far, and has created the solid piece of software that is Clojure today. Thus its own success is proof that it is a good enough process and is good for Clojure.
The argument against is that contributors find it too hard and too much work and thus very little contributors make it through the process. Though I didn't really see them mention any alternative process suggestion. It seems they were mostly wanted their patch to just be merged in without challenge.
Because when you invite me to your house, I do not gain the right to demand you rearrange the furniture. You built that, you put things in their place. If I want something for it I can only make a case for it, and that case hinges on convincing you.
No. Whoever is leaving should have left without ranting is the only issue I'm having with this aggravating distraction. Chas knows very well how Clojure is authored. I suppose some people believe their contributions or community status give them higher authority and a right to publicly pressure Rich Hickey. But in reality they are only doing more damage to the community and likely Richs creative process on the way out. If this is the price for their contributions I want to live without them without even thinking about it.
As a power user, to me this doesn't appear to be a community issue. A handful of individuals take themselves way too seriously and don't realize how they are hurting someone emotionally.
The entire idea that a different process would produce better results is an insult in the first place. The progress and effect we got with Clojure with no enterprise funding/influence is a true miracle.
This thread made me look at Clojure again (it has been a few years since the last time). Searching for Bayesian inference libraries I came across this: https://github.com/cemerick/raposo
"Never, ever, ever give a talk about a library or other code publicly unless it's in a public repo prior to the talk. Period. (Exceptions to this might be things like case studies and such.) Doing otherwise is surely irritating to talk attendees, but it's even more disrespectful towards organizers, as their acceptance of your talk may have been implicitly preconditioned on the attendees being able to benefit from the code/library/project in question."
Is the expectation now that when you talk about something it is necessarily going to be open source? (And from there the expectations grow and grow...)
One thing that I've found increasingly distasteful (I've noticed it in the React community, but it may be a wider trend), is the use of conference talks to announce/launch projects.
Thankfully it's still usually the case that the content of the talk is generally valuable. But ultimately, if I'm paying to fly somewhere and see your talk, I'm there to learn, not to witness your own self-promotion.
> You are responsible for your own needs. If you want things, make them.
>I am grateful for the contributions of the community. Every Clojure release incorporates many contributions. [...] Open source is a no-strings-attached gift, and all participants should recognize it as such.
>The time to re-examine preconceptions about open source is right now. Morale erosion amongst creators is a real thing.
Sad that it has to be said. I think as a creator you need to brace yourself for the reality of what it means to offer something to the world. There is a sort of normal distribution of consumers and some can be surprisingly toxic.
Interestingly, this isn't just isolated to open source. I've heard similar sentiments expressed by artists of popular works, including but not limited to:
- Game developers
- Authors of popular novels that have yet to finish ("GRRM is not your bitch")
I had been doing that a long time when one of my producers (on his first game) wanted to be on the forums to interact with "fans". I think he was excited and thought it would be satisfying to interact with people who were playing the game we developed. I remember thinking it would be like that when I started. Don't get me wrong, most gamers, like most people, are terrific. But they get drowned out by the disgruntled.
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.
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.
This is the rational approach, but it is not in accordance with human nature.
Human nature is fanboys. Picture sports supporters. They will perceive a relationship that you may have never intended. They will wave your flag and they will sing your praise and they will cheer you on. And they will expect you to live up to the grandiose image they have of you, and will punish you when you "betray" them.
I think people are certainly taking note of these "entitled" comments when they decide what to get emotionally invested in. If I know ahead of time you "wont be my bitch" maybe I'll save myself some grief and not get started with your series.
Bitcoin is an interesting case. It has very deliberately rewarded it's early adopters and fanboys, and that strategy paid of very well.
Not the same thing at all - those are commercial products. If someone has paid for a product and feels it was missold then yes, they are entitled to leave a review. Especially since cinemas don’t offer refunds to dissatisfied customers.
You know, I wrote a number of successful open source packages. By and large, feedback is positive, or at least utilitarian: bug reports, feature requests, questions. But there is also the occasional angry user, or, rarely, a simple thank you.
Recently, I published my first-ever commercial video game plugin. And was dumbfounded by the sheer positivity of the response. People thanked me! I got dozens of purely positive emails. I had never experienced such a thing in my Open Source work.
If we had more of that in Open Source, maybe maintainership wouldn't be such a burden.
I wouldn't dare writing just to say "thank you", it would feel like a no-op wasting people time. Instead, I would rather star the project on github. Did you consider those as thanks?
Someone said bad words to you on the internet? Close your browser tab: you're done. Learn that you can't please everyone and you're better alone than with bad company.
I don't know if it's because a lot of drama queens and marketing people populate social media but it feels like most people can't fucking live without the approval of everyone when reading some websites.
If you want to bring conference in (it's IRL, can't close a tab) here is how to react: when someone start telling you shit, stop speaking, turn 180°, go join another group of people. It's rude? So what? Some person is now fuming while you're stress-free and engaging with better people.
Learn to ignore people. Learn to say no. You don't have to please anyone.
How do you know when you are interacting with one of "those people"? Even better, how can I join a conversation without being written off as one of them?
Yes , it's the reality, i think it's better for the creator to learn and act to be the actual dictator. This might mean ignoring those community suggestion/request that they don't like. kinda like linus which I admire.
The attitude of many is strangely feudal: "I (potential contributor) offer my fealty (using your code) to you (author), and in exchange you owe me protection (features)." These people are under the impression that authors ought to be impressed that somebody uses their code, which is not the case. Lots of users are nothing but a weight that drags you down: if you want to swim, you must cut them loose ASAP.
This is an excellent depiction of the distinction between "free software" and "open source" as ideological frameworks. As licensing schemes, they're the same - but open source ends at the licensing scheme, as the author correctly points out. If you want to use it for a side project, great. If you want to use it to make money, great. If you want to use it to commoditize the operating system for your worldwide advertising infrastructure, great. If you want to embed it in your iOS app or in iOS itself (and the license permits doing so), great.
We will be guided by the needs of our users and the free software community. We will place their interests first in our priorities.
We will give back to the free software community.
In other words, free software is about you.
I would quibble with the claim that the open-source process is what produced Clojure in the first place. The open source movement has benefited from sailing in the same direction as the free software movement and using the same tailwinds. Without the free software ethos (which was behind GNU as well as a lot of the Lisp work at MIT), would Clojure have been able to stand on the same shoulders, and would it have attracted the community of users and the ecosystem of libraries it has?
Or I would rather say... Yes, "free software" has an ideological intention, that is, to make the software free for all its users, to protect it from exploitation using a strong license, and eventually leads to some forms of social change in the software world, as in "when we have enough free software, we'll kick out those dirty licenses, ever more, hackers, ever more".
But "free software" itself is only the means to an end, it's a technical and legal tool to accomplish these ideological intentions, and as a tool, it's a collection of code published under a license scheme. When the developers served their duties by providing the source to the users, the work is done. The developers have no responsibilities to implement anything for its users.
On the other hand, if someone writes free software because they wants some forms of social change, in this sense, the intention is not solely developing free software, but to pursuit an ideology though the development of free software. And this is done by a group of people in a community, like Debian, then they must be doing whatever is needed for this goal, i.e. be guided by the needs of the users.
In conclusion, "free software" is not about you, a free software community can be, and often is about you. But it is also legitimate if it's not, in the end, it depends on the community. Some people only care about themselves, some projects just want mainly the software, but may also care about users freedom, some projects want social changes, while others focused on improving the current status of a specific technology. There are overlaps, but there are priorities as well.
I disagree. Software projects that claim to be free-software instead of opensource (plus use a "contagious" license such as GPL) don't owe you more community management than the ones with an MIT license.
Most high profile project that explicitly claim to be free software in fact do not do any kind of community management at all and do not tend to actively seek outside code contributions.
In fact the community involvement in development as exemplified by GitHub (and SourceForge before that) is to a large extent invention of the same group that started using the term open source (for what is otherwise mostly the same thing as free software).
I'm being a little unconventional with my terms - mostly because the article is titled "Open Source is Not About You." Zach Tellman (a prominent Clojure community member who does not work for Cognitect) just tweeted a link to his post https://medium.com/@ztellman/standing-in-the-shadow-of-giant... about "open source" and mythmaking, which is a much subtler take (and, I'd guess, probably inspired by an older flareup in the Clojure community over governance).
It is, however, the case that open source under the GPL is a perfectly well-defined concept, as is free software under the MIT license. The terms refer to worldviews about the code and ethical obligations, not to licenses.
This is why my code is licensed MIT. It is a gift, you owe me nothing, I owe you nothing. It might not work, it might not compile, it might delete all your files.
I could have written the same last sentences as you, but using a GPL license. No difference. Licensing is not related to this. (PS: When you choose "GPL", if someone modifies your software, they don't "owe" you those modifications; they only owe those modifications to their users, and only in case they have users. Again, no community-management here involved, just distributing the sources.)
If you give people someone free code and it deletes their files, you could be liable. That is why software licenses not only have permission-granting clauses but also warranty disclaimers. (Those might not protect you in every jurisdiction.)
I think you are reading too much into the term "free software" as GNU was historically[1] no less easier to contribute to than Clojure is today.
The GNU definition of free software (and the 4 freedoms) make it clear that it is about users, but only inasmuch as their private rights to do what they want on their own computers. There is no sense that openly welcoming community patches is something that is involved.
1: It's entirely possible that the community has opened up more recently, but Lucid shipped a fork of Emacs in the 80s for similar reasons to the complaints about clojure today.
This is entirely orthogonal. Free software is ideological by design. Rich here is complaining that the culture surrounding open source grew its own ideology, and that it interferes with the very process & value proposition of open source software.
Rich Hickey has given so much to the world of software and systems design. The value exchange has most likely not been reciprocal. Nor has it been sufficiently respectful, based on this message. People like Rich that give so much are rare. And people that understand how to respectfully recognize that seem to be becoming more rare.
Of course, one can remember that life is not fair, and people are often shitty even without being conscious of it, and that Rich has freely chosen to pursue this path.
But this leads me to a few questions: If you agree with what I have written above, and what Rich has written in this message, then how can we tip the scales just a little bit further towards respect and reciprocation? What kind of gestures, gifts, and generosities do you think are appropriate? What improved efforts to educate consumers of open source software would be effective? Further still, what kind of culture do we want?
One that you can certainly do is to be one of the voices of positivity and gratitude.
If I enjoy or benefit from something someone has released into the world, I've started trying to send them an email of thanks.
Many times I've gotten responses back, and they are always really grateful for the support. As a hopeful creator with a small but growing following, I've gotten a few of these myself and they really are motivating.
I generally make it a point to never criticize anyone online, since they probably know everything they are doing wrong acutely well and don't need me to tell them again.
Python is currently adding a “thanks” command to their package installer pip. There are efforts to wire pip to monetary rewards. I believe that’s the right direction: identify where the rubber hits the road most of the time, and insert positivity and gratefulness.
This was actually an idea proposed by RMS probably 20 years ago, but I think he was talking about music. Essentially it's the busking model. The key is making that small donation extremely easy to give. And also to get big corporations to press that button.
It seems strange to me that you're so concerned with how we should try to be more respectful to Rich given the querulous and disdainful tone of his post.
The far more important and long-reaching gestures would be: expressions of thanks, and standing up for creators whenever unwarranted demands are made upon them.
Like "everyone can freely use and modify this, except the people listed in appendix C, who are specifically prohibited from using any part of this code for any purpose whatsoever".
If you get too shitty at the maintainers, you get added to the C-list, and get to take your shitty attitude somewhere else...
I think this also fits nicely with the backdoor thread posted earlier today. There is an immense amount of pressure and expectations put on folks who open-source things.
The other side of this is that open source projects are not entitled to users, or relevance. If they aspire to those things, then being responsive to their users and making something amazing that strangers want to use is part of the process.
Neither side has any particular obligation, but open source creates the most benefit when users and developers make an effort to be considerate towards each other.
I don't know why more people aren't pointing this out. It's almost as though people don't realize how much the value of Clojure comes from the community. Or aren't aware that many of the most helpful and constructive members of that community are burning out and leaving.
"At first, each community is defined by its potential. But as that potential is realized, the community begins to be defined by its compromises. That change is felt most keenly by the people who were there first, who remember what it was like when anything seemed possible. They feel fenced in and so they move on, in search of their golden city."
I've yet to see a non harmonious relationship between constructive and helpful community members and the core team.
I'm also not that sure the community contributes as much as you think. I use Clojure for work, and 95% of all value is from the core team only. I'm not trying to say the community is bad, I'm part of it, mostly trying to point out that it actually is quite disproportionate in relation to the core team, and I don't think we can criticize them until we (the community) actually step up and start being a lot more helpful and constructive.
As a serious user of Clojure, I just want to point out that one of my favorite thing about Clojure is the consideration that the core team has for its users.
I don't think this gist is targeted at users, but at other contributors.
As a user, Clojure is one of the best community I've ever been in. Where else do you get someone from the core team answering your questions in less than 24h ?
Design choices are well explained, the ticket process is well detailed on the Jira, the conj each year announce what to expect in the new version, and everyone is polite, inclusive and friendly to newcomers and beginners alike.
Imagine belonging to an expert, seasoned team that masters a given technique. Literally the worldwide top 1% for that technique works under your roof.
You don't take feature development lightly: each feature will be discussed and polished patiently within your team. And then you release it, for free.
Then semi-random people from the internet want to continue the discussions that were settled privately long ago, while also demonstrating this entitlement.
I guess that can be a maddening, constant stream of noise. One that cannot be dismissed harshly - you may be an expert, but definitely don't want to scare people off.
Kudos to the Clojure core team for resisting the stream in a classy, illuminating manner.
> Imagine belonging to an expert, seasoned team that masters a given technique. Literally the worldwide top 1% for that technique works under your roof.
That would worry me immensely. What sorts of things are we not realizing because we're not exposed to other ways of thinking? What sort of talent are we not training up because we don't know how to recognize it? And what do we do when some of the people under our roof retire?
Have you ever hired someone who worked at Google? They're quite probably in the worldwide top 1% for software engineering talent, and still they come out of Google expecting everything to work in a Google way. And conversely there are folks at my company - skilled software engineers - who I wish would go work at Google for at least a few months, because they've been here for probably ten years and while they're very good they've never seen how other people do things. They're skilled, but they simply have not had opportunities to learn deeply from the outside world, and in a field moving as fast as software, no single organization can keep up.
This is why open source exists in the first place. Whether or not you think there's an ethical imperative to share software, the whole idea of open source is that different companies can share source code to produce better results than in-house development and buying licenses to closed-source software would achieve. At some point, if you're on an expert team that works under one roof, you're going to stop being the experts in the thing, because the other 99% of people interested in the subject can all learn from each other, can try the things you dismissed privately long ago, can experiment at scales you simply couldn't imagine.
yeah, thats important, but its also not whats happening here. This is an argument between people who've contributed a great deal to clojure and clojures ultimate authority. Which is completely different then entitled randos drive-by commenting and demanding accommodation.
I haven't used Clojure much but what I hear is mostly great. And I love this rant, its always refreshing when people speak their minds.
But.... Rich is pushing things a little too far I believe.
On the front page of the Clojure web site, under the section 'Rationale", his very first 6 words are:
> "Customers and stakeholders have substantial investments [...]"
Those words do not sit well with (from the rant):
> "[..] you are not thereby entitled to anything at all. You are not entitled to contribute. You are not entitled to features. You are not entitled to the attention of others. You are not entitled to having value attached to your complaints. You are not entitled to this explanation."
I get it, Rich is making a point, and its a fair and unarguable one - if he indeed has no loyalty or feeling whatsoever towards said Customers and Stakeholders.
But in the real world, we want our work to be valued by others, and I'll bet that the stewards of Clojure feel just the same and maybe shudder just a little.
Rich Hickey stands for good design. That means saying "no" to a lot if ideas that are good, but not part of the vision, and it means not running experiments on your users in the main releases. Whether he reaches that ideal, I dunno, but he lays out the vision pretty clearly when he speaks. It isn't the only way, but it is Clojure's way.
When he talks about customers and stakeholders, he is talking about people who have bought in to that design. It is very easy to support his position here. Rich knows exactly how he wants to program and the man is a visionary of data-driven programming and thinking. If you don't like that vision, maybe don't use Clojure and find a different lisp.
Great design is a very foreign idea to a lot of mainstream software developers - most of them, sooner or later, go for the "big rewrite" because they didn't get the design right to start with. Things like Python 2 -> 3 spring to mind (breaking changes to print! whoever thought that was a good idea didn't respect the language users). With that rational, he is promising not to do exactly what the Python people did.
There is a big difference between design and bug fixes. There are many small tickets with bug fixes already written that have not been merged into Clojure citing Rich’s time. Sometimes months or years go by, even when the Jira thread includes supporting comments from Alex Miller at Cognitect. Small fixes that improve the language without altering its design, making core functions more stable with edges cases, and they never make it into the language.
It's caveat emptor, even when you pay $0. When you choose an open source tool or library for your project, or even a closed source one, you need to evaluate what support / bug fixes / modifications / enhancements you will get in the future and if it will meet your needs. Are you prepared to fork or workaround things where it doesn't meet your needs. Or is it better to choose another library or tool?
I kind of wish people complaining about Clojure's development process (and of other open source projects) would just create a fork and implement their own ideas.
This way, everyone could benefit from the experimentation and likely some of their ideas would get rolled into the root project once they have proven themselves.
They mostly don't matter to users, because most forks fizzle out due to lack of interest, unless there's a really good reason for the fork. If the original maintainers aren't doing something weird like re-licensing under a more restrictive license or closing off development and refusing good patches from the community, it's very unlikely a fork will gain enough traction to end up on the radar of most users.
We've had a few forks of our projects over the years...most often, there's just one initial commit with a few minor changes and some big words about how cool it'll be when the community can steer the ship...and, then nothing, forever. The thing about forking a big project is that it takes a lot of time and effort to make it better, or even significantly different, from the project you're forking. "Do not fork lightly" is good advice, but mostly because it's gonna be a waste of time in most cases.
It has actually worked out pretty well in the case of Typelevel Scala. Users are free to compile using mainline Scala while using libraries that are built in Typelevel Scala. In most cases, this isn't even exposed to the user.
> To be honest, I could use that money in my retirement account, having depleted it to make Clojure in the first place.
A perfect example of the significant cost and personal risks people take on for the benefit of producing open source. I'm as glad Rich is saying this as I am he made Clojure (and open sourced it!) in the first place.
I run a few OSS projects, among which one with 10k+ github stars that has a decent size community. While I recognize my own personality in Rich's post ("if you don't like my direction.. there's the door") for some reason I ended up running this project with the attitude that everyone I am interacting with their time, insights, and needs are just as important as mine. It's been very refreshing. It makes people very eager to contribute, and there's close to 0 hostile behavior in the community. It really works magic.
I have no doubt that Rich's time and his direction of Clojure are endlessly more important than the average community member, as a fact. But you CAN'T communicate this way! Interacting with someone where before you start there is the assumption that someone is way more important cannot result in a good interaction. Even if it is a fact, even if both people involved know it, you will be much better off if you act like it doesn't exist for the purpose of communication.
Of course, time is limited, but I find there is an art to giving short reactions that are still respectful in this way. And it is not like Cognitect entirely does NOT want there to be community interaction (like Rich himself says), so it is just a question of optimizing these interactions.
It still boggles me that Jira tickets with small bug fixes to real problems confirmed by other members of Cognitect have never been merged, due to Rich’s time. Simple fixes to core functions that make the language more stable for edge cases without breaking design or backwards compatibility. Fixes that the Jira threads reveal others at Cognitect support patching and for which patches have already been written. Tiny fixes with little code involved. I understand being conservative on new features but isn’t it in everyone’s interest, including Rich and Cognitect’s, to fix actual bugs?
The answer tends to be that if the bug doesn’t affect Rich personally then it does not get attention. That doesn’t seem healthy for the language.
We actually never got our bugs solved. My particular favorite was CLJ-1741, which made reloading code with Cursive basically not work in our code base. Opened in 2015, effectively abandoned to its fate in 2016.
I see Github playing a big role in bringing about this situation. The collaboration model focuses on the "who" of software development and not the "what". It used to be people were concerned about making a piece of software that did something interesting. Now it's all about how many stars, forks and followers you can get. Github made it too easy to "collaborate" and now you see any number of non-developer interlopers pushing project owners around. There needs to be a new model that's not so focused on the social but is focused on the tech and just the tech.
He is correct that open source developers don't "owe" anyone anything. But this is kinda missing the point.
The point is that if you have a bad development process, people are going to have issues. And these issues are real.
Even though you have no "obligation" to solve these problems that you have created for other people, you shouldn't be surprised if people bring them up, or perhaps even fork the project with a bunch of other people who also have problems with you.
Sure, the community does not own your time, but neither do you own the community. A community is fully within it right to do something else with their time, or convince other people to contribute to a different project.
> Even though you have no "obligation" to solve these problems that you have created for other people...
Publishers of open source code don't create problems for other people. People who accept that code into their projects assume those problems for themselves.
If an open source package has bugs in the forest and nobody is around to install it...
> But kindly don't burn the community down on your way out, with self-serving proclamations
This is him complaining about what the community is doing. The community is free to do what it wants, and he is making some sort of statement as if he owns the community in some way, and therefore can decide what is or is not "burning it down".
Convincing other people to leave the closure community (IE, burning it down) is a perfectly reasonable thing to do if there really are problems with it.
Complaining about what the community is doing, is him making the same mistake that he is complaining about other people doing.
1) The problem is that not every company has the resources to maintain its own fork of the code base. Some of us are one man bands, work in quite small teams of less than 3 or 4 developers. This idea that people have the resources to maintain their own fork of the code is crazy.
2) Two it creates fragmentation. Fragmentation creates defects and incompatibilities.
As I gotten older I pretty much realised that unless it is backed by a professional company I am not using it. There has been consistent stream of fiasco, drama and general unprofessional bullshit in the realm of open source I am quite happy I've mostly stuck to doing the majority of my work with .NET and SQL Server.
(Downvoters: Did I read his essay incorrectly? The reddit post from 1 year ago and the github post today seem be the same theme of managing the community expectations of Cognitec.)
Rich put it well that Clojure is not closed, it is conservative. He made it to solve the problems he encountered in the industry, which were large multithreaded proprietary systems. It is a business first language (cognitect is a consultancy, after all). The fact that so many hobbyists like me ended up using it was kind of a happy accident.
These two audiences don't have completely opposed interests, but they do have different priorities. Businesses care about stability; they don't care much about whether the language accepts PRs on Github or conducts twitter polls. I accepted that a long time ago, and I'm still using it six years later.
>Broadly yes, but I'm guessing this one was sparked by this thread
Ok, I see the possible confusion. I wasn't trying to say they were related to the same event. I was trying to point out they were related themes.
When I read today's post, I had an immediate sense of déjà vu. No wonder, he used the word "entitlement" repeatedly in both posts a year apart. (Counted 11 times in today's post and 4 times in October 2017.) He also mentioned personal sacrifices of losing money on Clojure in both posts. (The "retirement money" in today's post and "$200k" in last year's post.)
I don't follow Clojure closely but the meta question/observation is that there seems to be a profoundly broken misunderstanding and recurring pattern of negative interaction between the Clojure community and Cognitec that causes Rich Hickey to express his frustration in way that other folks Ruby's Matz, Rust's Hoare, didn't have to express. (Maybe Hoare left years before the Rust community could turn on him and accuse Mozilla of holding back progress in the language (and therefore Rich's predicament is inevitable if one stays involved long enough) -- I dunno.)
Yes, different specific triggers but the same type of frustrated response. I thought they were over a year apart but you're saying the frustrations are unleashed every couple of months so that's news to me.
I haven’t used Clojure much in the last two years, but this is the part I remember is most surprising, and completely congruent with what Rich describes. You hear about this thing, it is a Lisp, and you wonder if it might be some edgy thing, moving fast, breaking things, showing off this mighty power (that Paul Graham wrote about) of Lisp.
And it is a little bit of that; but it's also a lot more of an intentionally conservative, even boring, extremely practical tool for building real things in a concise manner. In this way it fits into the Java ecosystem well, alongside many other very boring, robust, proven, reliable chunks of code.
Much of my work today is in the Node/NPM/JS ecosystem; although that has its advantages also, some days I really miss the boring reliable conservatism of Java and Clojure!
I would argue that if you release an open source project, you do have a responsibility to communicate enough about your intentions that potential users can base their expectations accordingly.
That doesn't have to be at any particular level. But if a project is unmaintained... why not tell people? If you are sharing a project in case it's useful to someone but don't really intend to deal with any external bug reports or feature requests at all... why not just clearly advertise that?
Nope, you're not entitled to anything. A license is just a license. You're free to use the code. If the releaser gives you no communication about expectations, then it's your choice to use it or not. They're obligated to give you anything, not even the time of day. Enjoy your free code, or don't.
Although there is of course no warranty, I think it's fair that when projects have marketing websites saying how great they are and encouraging widespread use, users can complain when the software isn't fit for use.
If you're going to be strict about how you don't owe anyone anything, it might be a good idea not to undermine that message in your marketing. Better to tell people all the reasons why they shouldn't use your code. Not for production! There may be bugs that you have to fix yourself!
And then work with developers who don't scare easily.
This post is absolutely correct. All your entitled to (if anything) is the code, as is.
You're not entitled to:
* Community engagement
* Bug fixes
* Timely pull requests
* Anything else
You get the code as it has been released. Whatever you do with it is up to you. The finished product you build using the code you have found is your responsibility and yours alone.
> Morale erosion amongst creators is a real thing.
It reminds me of a project called aurman [1] (a great AUR-Client for Arch Linux). Due to the 'feedback' from the community, the main author went from loving to work on his project to hating it. In the end, he stopped the public development to protect himself from the negativity.
I think there’s a time though when an open source project becomes so dominant in its field, that alternatives become few or untenable. In these cases were all at the mercy of the market for having consolidated on a set of choices. The mindshare around the project gives maintainers a tremendous amount of power over others.
Many mainstream projects fit into this. It’s not feasible from a business perspective to get to fork Linux or MySQL. There’s alternatives, but if they don’t work not everyone can spend startup funding to build a NoSQL database.
In these cases committers have a tremendous amount of power and often get disconnected from practitioners.
Android runs on billions of devices and is a fork of Linux. There's two or three commercial forks of MySQL, I think Percona started before Sun bought MySQL, but I can't remember for sure anymore.
People are inherently selfish. Everyone is looking to better their own self-interests, seek validation, and seek attention in life. A community - any community - is made entirely of these people.
An effective leader is one who can play to the strength of this fact rather than fighting it. You have thousands of people willing to spend their time for you. How can you make their interests align with your own? How can you convince them that your self-interest is their self-interest?
Funny, but I don't think calling people entitled is the answer to this.
I maintain a few open source projects that many developers use (along with many more projects that no one uses) and I get like one PR a month. It seems like some developer’s entire workflows depend on some of the tools and libs I maintain, but I don’t even use the damn things myself.
That seems like the perfect case for self interest: make this thing you use all the time work better for you. The code is usually fairly clean and the contribution process documented. And yet all the help wanted issues just sit there.
How have other maintainers been able to encourage more valuable community contributions?
Could it be that people who use your OSS think you have an obligation to them, because you marketed your software in a nice and pretty gift wrap package (eg. web page) and they chose yours over and alternative (ie chose to invest their time and effort on it)? They chose to "fall" for your marketing over that of another project.
Maybe they feel that by choosing your software over an alternative, they're also helping you (since it's your project after all) and they atypically expect some things of you?
P.S. I'm not taking sides. This is just a shower thought.
Although I appreaciate almost all opinion articles and videos posted by Rich, what I read here is that Rich seems to see his project about himself which fits his previous behave as Clojure's Dictator For Life. In other words, he could never remove himself from the equation or make clojure an independent long standing self directed project.
In general terms of OS project, I think the first premise is already flawed. What if there were open source projects meant to satisfy their users or public? Or just iwth very different goals than yours? Do you even think that software is just finished when it is released? that fanbase should be allowed? What if Rich itself is the main bottle neck for his own masterpiece?
The only people entitled to say how open source 'ought' to
work are people who run projects, and the scope of their
entitlement extends only to their own projects.
Now, he should answer this own questions and make his own logic for his own project. I personally always saw open source as complex as a society is; as complex as an MMO game game can be. (including actors such fanbase, devs, sponsors, investors), etc.
It's painful how many people don't seem to think this way. If you've ever contributed a patch to an open source project, do you think you should be obligated to maintain this patch for the foreseeable future? If the answer to that is 'no,' then why would a greater contribution, such as an entire project, be held to such obligations? It's disappointing.
A decade ago I found Rich's way of communication tough to swallow and borderline abusive, but re-examining it with the acceptance the years of using probably the most expressive and versatile language on the planet I find it refreshingly clear and to the point. And he's absolutely right of course, his time is just that, his time.
Arguably the best and most important thing an open source author can do is engineering their code the way as easy to understand and extend (this doesn't mean an over-engineered architecture, quite the opposite) as possible so whoever wants something particular could really easily add/change it with an extension or by forking and editing the core code. This done you can really legitimately direct those asking for what you don't feel like doing to do it themselves. Another great idea, IMHO, is hosting issue tracking on GitHub and making it the only accepted channel for feature requests and bug reports.
Making github the only accepted channel for anything is hardly a great idea. Perhaps if you used "an additional" instead of "the only" in that sentence...
I believe this way people are more likely to be reasonably self-moderating and specific and less likely to engage in personally emotional argument with you than if you use e-mail. It will also give people convenience of filing a bug/suggestion without having to register on yet another bug tracker given they already have a GitHib account (who hasn't?). Needless to say using a single bug tracking system and input channel is much more convenient for everybody than if there were many.
> We take some of what we earn, money that could e.g. go into our retirement savings and instead use it to hire people to work on Clojure and community outreach, some full-time. To be honest, I could use that money in my retirement account, having depleted it to make Clojure in the first place. But I love working with the team on Clojure, and am proud of the work we do.
... and then this...
> Open source is a no-strings-attached gift, and all participants should recognize it as such.
Is control of the closure project part of lead dev's business model, and the part about dipping into retirement just an "open-washing" of "I decided to start a business?"
Otherwise this sounds like an extremely unhealthy and unwise "gift" on which to spend one's retirement savings.
Aren't gifts _usually_ at the giver's expense? Anything else is a transaction, surely.
I think the only point being made there was that this gift is expensive but he's happy to give it. The way I read it, he's happy to give out free iPhones, but asking/demanding a battery-charging case and extra Lightning cable on top might be pushing his generosity.
> Aren't gifts _usually_ at the giver's expense? Anything else is a transaction, surely.
Usually with open source the "gift" is the author/maintainer's time. "Gift" in quotes because there is usually immense pleasure in creating and controlling a project.
If the author/maintainer is ranting about the sacrifices they make for the project, that usually means something has broken in project development process. And I've never heard of another project where the author dipped into their retirement savings and built up less savings than they should have to support their authorship of a project. That's a problem that should never happen, not ammunition for rationalizing the pecking in a project.
The iPhone example doesn't work. I can't send a patch to ostensibly improve the hardware (or even software) of an iPhone. The audience the author was addressing was other developers presumably complaining about low patch acceptance and long wait times. In that light, process conservatism and generally low patch quality are persuasive arguments for the status quo. "I'm sinking my retirement into this" and "community-driven development is a myth" are not.
If I'm forced at work to work with mediocre FOSS stack without support culture (even for paid tiers), it is about me. I'm not choosing to work with a subpar farce of a technology like npm, it's forced upon me.
I'm not a user of Clojure, but I'm a user of other FOSS tools (Docker) for which I've had complaints.
Though I have potential issues here, I think it is important that this be said. It highlights missed expectations. This open source thing is a weird new(ish) world, and we need to be on the same page. It's been a few decades, but perhaps we haven't quite adjusted yet. Or maybe this hippie thing actually doesn't work, which would be a real shame.
The fact is that we rely on it. And I think that this really is an alternate mode of creation. I could be wrong but I don't think the idea of "community development" is something that was recently made up. It's part of the Free Software ethos. Perhaps what is new here is a notion that there not be a party at the top of each fork who has ultimate responsibility.
A pure gift, take it or leave it, no strings attached in either direction, is fine, and should be appreciated. But it's useless to users who need to rely on what you've produced. If the project is not subject to the demands of its users (which includes contributors, to the extent that they are users with demands that they are willing to fulfil themselves) then it's got a serious disadvantage over commercial software without a free distribution model. It's not akin to a serious tool for sale. And _if that doesn't meet expectations_, people are within reason to push back.
The other side of it is that there have to be limits, of course. There has to be respect for the producer, their time, their preferred mode of management, the limit of the scope of the project, etc. There have to be judgement calls made, just like commercial software without a free distribution model, as to what does and doesn't make it into the project. For all these reasons I can see that it's important that a producer pushed back here.
But if the producer doesn't voluntarily take on some level of responsibility as part of running the project, whatever the terms may be, then at the end of the day the project can't be relied on within the economy. This is not a demand on the author of this post. He is entitled to treating Clojure under whatever terms he wants. But somebody has to, for it to work in our system.
I think the solution is just better messaging of expectations. What this project is. What expectations should you have as a user. What expectations should you have as a contributor. Now we can all look at it as a reference point, and decide: Do we want to rely on this? Do we want to spend our time working on this? Do we have a basis for complaint?
Really, this is the same set of questions that are answered in any business arrangement. Perhaps there needs to be a SOCIAL_CONTRACT file next to LICENSE, README, etc.
I think if you are doing an excellent job with your project, noone has time for you[dev] , as they are too busy enjoying your project.
its like when granpa tries to get in on the basement gamefest with the kids.
let them play, your best contribution is to make more toys for them to play with and let come to you and ask for more.
It gets pretty tiring on HN/reddit to watch people demand so much shit for free, namely other people's time. If you've ever run a project with users (most people haven't), you've experienced these demands first-hand.
It's nice to read these sorts of posts when it's getting you down.
For me it was the recent outrage at Elm's creator. Random people on HN/reddit basically acting like they were some disgruntled paying customer. You can see a common thread with Rich's defense of Clojure.
Would you mind giving a bit more context/link to the HN discussion(s) about Elm's creator? I've seen the JS event-stream kerfuffle stuff posted all over the internet today, but I havn't heard about the Elm thing.
Elm is a very locked down ecosystem, heavily influenced by a single lead developer (Evan Czaplicki) with a very small team of assistants. Development is slow, and focused heavily on what Evan thinks is best; features he doesn't use or doesn't think are working out can (and have) been removed. If he doesn't think a bug is critical, it will be ignored. If Evan decides that the way a chunk of the Elm ecosystem works isn't really in line with his vision, then he'll rewrite it. If that's a breaking change, so be it. If maybe Elm goes a release or two with an important feature not working because Evan is halfway through rethinking something, then sure, that's a thing that happens. The Elm dev team is small, their resources are limited, and they're focused on moving the project forward.
Some people see this and go "okay, I'm fine with this, I like Evan's vision and I want to see where this is going"; many of them use Elm in production and accept the occasional bumps in the road.
Others are interested, and happy to watch from afar, but are waiting for Elm to hit some form of 1.0 release or otherwise announce that it's ready to be used in production before making the jump. (I'm in this camp; Elm is clearly not suitable for me today, and that's fine!)
And some take the entire thing as a personal affront. Entitlement is an issue across all of open source, but Elm has some characteristics that makes it especially prone to driving a certain type of user wild. How dare Evan change Elm internals in a way that breaks the way they were using Elm?
Yeah, Rich is obviously right. Concerning Clojure, or any Lisp variant for that matter, I came to realize that the cost of the unusual prefix notation -- which does cause inconvenience to people trained on using infix -- needs to be offset by the usefulness of defmacro, i.e. the possibility of using macros. Paul Graham insists that it is surely worth it, but unfortunately, he does not show convincing examples. So, I keep sitting on the fence. I am ready to be convinced, though, with compelling examples of a problem that I cannot possibly solve with defun and for which I would need defmacro.
The parenthesized prefix notation is advantageous because it is unambiguous and easy to format. People trained on infix still make mistakes due to associativity and precedence: mistakes in understanding an expression and in writing the correct expression which matches their intent. Their skill does not translate into unfamiliar languages that have unfamiliar operators with unfamiliar precedence and associativity rules.
The user of a Lisp benefits from the development which has gone into the language/implementation. That development is lubricated by the structure of the code. The Lisp programmer does not only write new macros, but uses existing ones, either in the language/implementation or third party libraries.
There is no problem you cannot possibly solve with defun (plus escape hatches to access any aspect of the host environment), because defun gives you access to a Turing -complete computation model.
This is simply not a genuinely honest way to evaluate tools. Gee, I'm not convinced that there is a text editing problem I can't possibly solve with ed if I bash at the keyboard long enough; so for now I will keep sitting on the fence.
possibly isn't easily, efficiently, maintainably, and so on.
I think that programmers would generally be willing to overcome the inconvenience of the unusual notation, if the advantage of using defmacro was obvious from good examples to which they could, at least, relate. This question was also asked on stackoverflow: https://stackoverflow.com/questions/267862/what-makes-lisp-m.... My opinion is that the examples in the answers are neither obvious nor compelling. Hence, I am still waiting for better examples.
I'm guessing that this is a response to the current trend towards Codes of Conduct, which are best understood as part of the Long March through the Institutions, a politicization of things that aren't inherently political.
Although, there's something to be said for some potential overlap here. A lot of Codes of Conducts are basically being demanded by people who're not a part of the project.
Rich's point stands up well in response to that sort of thing: if you want it so damn much, fork it, do it yourself, and leave me to do what I do best.
That's the true beauty of open source, that you can just fork, do it yourself, and there we are. If your project is so much better than the original, people will flock to it. If not, well, at least you could still do what you did.
>> 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.
If I make infinite bread loaves and you're allowed take some loaves and _also_ see the recipe, that is quite clearly sharing by every definition out there.
We've banned this account for repeatedly breaking the site guidelines and ignoring our requests to stop. That's not ok, even if some other account was wrong and/or broke the site guidelines as well.
Rich Hickey needs to stop poking people in the eye with a stick.
> You are not entitled to the attention of others. You are not entitled to having value attached to your complaints. You are not entitled to this explanation.
This could be handled much more diplomatically. What he's saying here is "fuck you and your needs". Opportunity cost waits for nobody, but taking a second to not provoke people is a good idea.
> We at Cognitect have to show up to work, every day, to make a living. We get no royalties of any kind from Clojure.
Ditto for the people who wrote open source libraries, some that are critical for Clojure's adoption. In fact they typically did this after working a 9-5, rather than during it.
> To be honest, I could use that money in my retirement account, having depleted it to make Clojure in the first place.
"Look how much I've suffered for you!" is about as effective for leadership as it is for parenting.
> But kindly don't burn the community down on your way out, with self-serving proclamations.
That's a nice "fuck you" to frustrated developers. "Shut up with your complaints and go away" is a bad community management technique.
What's next, people who sell cars aren't responsible for making sure they're safe? People who sell food aren't responsible for whether it gives people food poisoning?
If you release a product then at the minimum it's your responsibility to make sure it's not going to harm others. If you can't do this then you shouldn't be releasing open source software.
Adding a disclaimer at the bottom doesn't absolve you of gross negligence.
"Sell" is a pretty important word there. There are laws and regulations for those, and neither comes with an explicit license saying something like "disclaims all warranties and conditions, express and implied, including warranties or conditions of title and non-infringement, and implied warranties or conditions of merchantability and fitness for a particular purpose."
> neither comes with an explicit license saying something like "disclaims all warranties and conditions, express and implied, including warranties or conditions of title and non-infringement, and implied warranties or conditions of merchantability and fitness for a particular purpose."
Because they obviously would be not legally binding. Again, you can't absolve yourself of gross negligence any more than you can sell yourself into slavery. And legally speaking, selling something almost always includes giving that thing away for free. (Except for in a few cases where gifts are specifically exempted, like for some low-level drug crimes at the state level.)
Companies don't care about making products safe until government steps in and forces them to. Unsafe food was not "next", it was the norm until Upton Sinclair wrote The Jungle. Unsafe cars are not "next", they were the norm; seatbelts were first recommended by a surgeon in 1930 who went on to form the Automobile Safety League of America, they weren't mandatory until at least 30 years later with seat belt legislation [1], or airbags legislation in 1998 [2].
Remember .. cigarettes? Arsenic Wallpaper and cloth[3]? Radium cosmetics [4]? Toasty warm Radium blankets[5]? Shoe fitting x-ray fluouroscopes[6]? Lead water pipes[7]? Sugar? Guns? non-fire resistant household furniture? Dinitrophenol[8]? Asbestos? Leaded petrol? CFCs? Unsafe buildings? Bisphenol-A? BSE related beef? 3D printers and their carcinogenic particle side effects[9]? Trans fats[10]?
and then why we have things like the CE marking safety standard in Europe. On and on, products are harmful by default until government steps in and forces manufacturers to make them safe(r). The free market cares about profit, not people.
What's next, people who make products are responsible for making them safe?
While the message is partially kind of correct, the delivery lacks everything that's humane.
> The only people entitled to say how open source 'ought' to work are people who run projects, and the scope of their entitlement extends only to their own projects.
If this is the case, why open source or publish it in the first place? If you want people to read the code, but not interact with you, why not write that into the license? Why not use something like CC-SA?
> As a user of something open source you are not thereby entitled to anything at all. You are not entitled to contribute. You are not entitled to features. You are not entitled to the attention of others. You are not entitled to having value attached to your complaints. You are not entitled to this explanation.
Looking at that last sentence, then, why not STFU, Mr. Hickey? Assuming the "users" are Clojure programmers, if they're entitled merely to nil, why bother with this angsty rant?
> Open source is a licensing and delivery mechanism, period. It means you get the source for software and the right to use and modify it. All social impositions associated with it, including the idea of 'community-driven-development' are part of a recently-invented mythology with little basis in how things actually work, a mythology that embodies, cult-like, both a lack of support for diversity in the ways things can work and a pervasive sense of communal entitlement.
This is completely wrong. The reason we have open source in the first place is years long, decades long, determined community effort. Mr. Hickey is not entitled to change the definition of F/OSS.
FOSS is the mantra of a particular community-oriented software-development zeitgeist, where things are developed by a community, without a project maintainership per se—i.e. where "the project" refers to whatever the most active fork of the project is, rather than to the project as maintained by some particular BDFL.
FOSS projects are usually maintained under the aegis of one or more software foundations, like GNU or the ASF.
"Open source", on the other hand, means exactly what it says. Microsoft does Open Source. Apple does Open Source. Oracle does Open Source. It means exactly as little as the image conjured in your head by that list.
It's not that simple. Open source projects, including Clojure, benefit from the community through bug reports, documentation, free user support, articles, etc.
To make it as simple as you suggest, there should be a code repository and nothing more. I don't think that's the case in the majority of open source projects or even what Clojure desires.
That being said, if you're not contributing back to a project (in any sensible way, not just code) maybe you should tone down your demands. I completely sympathise with author but things are a bit more complex in reality. Ignoring the benefits of these interactions/contributions is not fair to the rest of the community that is contributing. Maybe the author does that feel that's currently enough? I can totally relate.
FOSS is just "free and open source software" - a catch-all for both camps to avoid offending anyone. It doesn't imply any particular development methodology or project maintainership.
I do not think it's fair or correct to confine Open Source to that definition the last paragraphy of your comment implies. It may only be a subset of Open source. ASF itself defines what it does as Open Source.
What's described in this rant is basically "Source Available". Open Source means more than that, per ASF, per OSI, and per many who publish software under non copyleft licenses.
> If this is the case, why open source or publish it in the first place? If you want people to read the code, but not interact with you, why not write that into the license?
Because there's a difference between 'can' and 'must'. It's great when people use my OSS work, give feedback, and even file bugs. What's not great is when people adopt the position that they're entitled to a fix right now (or ever), or that they're entitled to new features or design consideration for their minority use case. In summary, strawmanning someone else's argument is bad, and you should feel bad.
> [W]hy bother with this angsty rant?
Managing large OSS projects is about doing things at scale, like answering a question exhaustively once, in one place, so you can refer back to it instead of having to explain variations of it repeatedly, ad infinitum. As far as 'angsty', maybe start with a little humility: check your own biases before reading an attitude into someone else's message.
> This is completely wrong.
Nope, you are. Both in the technical/legal sense and the historical sense. Recommended reading: The Cathedral and the Bazaar.
Please keep nasty internet tropes like that one way, far away from Hacker News. If you'd review the guidelines and follow them from now on, we'd appreciate it.
Though Rich is right, it pains me to read this because it is indicative of some disputes in the clojure community. I might be mistaken, but it seems that Rich is reacting to Chas Emericks' twitter post (https://twitter.com/cemerick/status/1067111260611850240). In his comments he has stated: "Finally, from a practical perspective, my core-level contributions always came from some source of pressing need in an actual, present, needs-to-work project. If I know a problem isn't going to be triaged for months and solved for years, then I'm out."
So this is not some grieving random person from crowd - Chas is a person whose libraries and contributions I value tremendously and he certainly made LOTS of contributions to clojure OSS landscape for free and out of his good will as well. So ultimately this feels like your parents are arguing (which is never a good thing) - you like them both and you just want the arguing to stop and you just want everybody to live together in harmony. But here you go, Chas has moved away from clojure now. And I have to say I am very sorry to see him go.
Rather than reply to any of the various downthread issues, just a few clarifications:
* I don't know exactly who Rich is responding to, but I can't imagine it's for rando users who drop off drive-by TODOs for maintainers. More likely IMO it's in response to a number of people who have contributed significantly to clojure itself and to supporting projects and resources that have spoken up in recent times with various critiques.
* I'm super uncomfortable with any comparison to this kind of "dispute" as being anything like that between parents, etc., though I can see how some might think of it like that. Really, it's a disconnect of expectations and a lack of communication, which I'm glad has been resolved definitively.
* I do still use Clojure (though more via ClojureScript than otherwise), it's just not my primary rig anymore, and I'm strictly a user. The contribution process was a minor factor, not the driving rationale for my looking elsewhere; though, as I said in the posted tweets, I surely wouldn't have tarried so long if I knew earlier what I know now.
Thanks Chas for responding. Apologies for the parents metaphor if that made you feel uncomfortable - since at the time of my writing lots of comments on gist and HN were concurring with Rich and talking about "weeding out toxic personalities" I was just trying to come up with a metaphor that would offer a different perspective - that this is a type of disconnect that benefits no one and that there is no side that is clearly "good" or "bad" since all sides are needed for the whole ecosystem to work. Rich's statement was aimed at some core contributors (I am guessing now probably a bit more at Tim and less at your follow up tweet) and that worries me. Imho this situation is a lose-lose scenario: for Cognitect to lose contributors, for contributors to have spent hundreds/thousands of hours in vain and for anyone from clojure community who placed his bet on clojure and invested substantial time in learning/using/evangelizing it (affecting his/her market value in the process). Anyway thanks for all the work on clojure! I am still using some of your clojure libraries!
Normal people who are using the software to get something done just maintain a local fork where they can fix fires as fast as they want, then treat upstreaming (if any) as a background task that is allowed to take the necessary time.
E.g. numerous GNU/Linux distros maintain local patches for numerous packages: kernel, gcc, glibc, ... Some of these take years to get upstreamed, if at all.
The problem is that this process doesn't work so well for people who just want to leave their imprint on that project (that one and only official project, not their private fork).
Saying I'm not going to use this as my main tool if I can't have a more or less free reign in shaping the destiny of its one and only official version comes across as a bit of an infantile tantrum.
1 reply →
> "If I know a problem isn't going to be triaged for months and solved for years, then I'm out."
Some problems are easy, low hanging, do it yourself. I guess that's not the issue here, but it's worth mentioning as a lot of OSS projects don't cater to solving these. (Expose some little bit from an underlying lib, make something configurable, etc.) And there are the uh-oh we have to refactor half of our codebase to solve that one by the way totally valid problem. And that's usually not a one weekend "project", and it is understandable, that it might take years.
And at that point, I feel that the entitlement of "make this work for me, because there's a project that depends on it" is the problem. Sucks to be the guy who have chosen the wrong tool, even if it looked like the best tool. It happens all the time.
As someone not in the know, Rich's post seems like an extremely aggressive and arrogant piece. When you put it in context, it does make more sense.
> As someone not in the know, Rich's post seems like an extremely aggressive and arrogant piece.
It seems that way? To me, it seems like a reasonable response to how many people treat any kind of volunteer-led effort.
For example, I help mod a fairly popular subreddit, r/cscareerquestions. Now, we don't have a problem with people suggesting changes to sub rules or have meta discussions and even complaints. No community is perfect, the mods certainly aren't, etc.
However, the vast majority of complaints are of the completely useless variety. They're the vague one-liners -- "this sub used to be good, and is now bad for generic reasons I will not elaborate on" -- that usually have no clear basis in reality, nor any practical solutions even to the extent they're true.
And when I try to earnestly engage with people who have the most upvoted complaints, 95%+ of the time, there's nothing there. Probably half the time they just don't respond, half the remaining time they just loose another snipe or parting shot before disappearing, and most of the rest is something in the set of {doesn't actually happen/no evidence; assumes everyone agrees with them; problem is actually well-diagnosed but the proposed solutions are laughably naive}. The number of complaints or suggestions that are meaningfully actionable is very, very low.
What I've found looking at other subs and ours, is that generic complaints about sub quality and mod team actions are a quick and easy way to upvotes, but it's rare for someone to actually be well-informed on the topic and have actually thought through the problem and solutions they suggest.
So when Rich says, "Did you know that most patches/issues have poor problem statements, no description of the plan (read my code!), no consideration of alternatives, no tests, no designs, and are ill-conceived and/or broken in some way?" that doesn't surprise me in the least. Even when people nominally want to contribute, they usually don't seem to try very hard. For me, it's gotten to the point where I'm writing a guide for subreddit criticism and suggestions to try and improve the quality of the complaining.
tl;dr - even when something is reasonably well run by volunteers, people love their low-effort gripes and snipes
12 replies →
It could easily have applied to dominic and the earlier npm fiasco, though.
People are getting a bit entitled as to what an open source maintainer has to do for them.
8 replies →
> Though Rich is right, it pains me to read this because it is indicative of some disputes in the clojure community.
I am genuinely curious why you, or anyone else, would think he is right. I can see why people would agree or why he wants to do things a certain way, but to be right you have to have arguments backing up what you are saying. I don't see that in this post. Am I missing something?
> I am genuinely curious why you, or anyone else, would think he is right.
Because Rich has the rights to do what he wants with his time and money. (Like everybody else.) It is completely within his rights to establish his own governance and contribution model for his version of Clojure. At the very least, I don't see an argument why it's NOT within his rights to do so.
Of course, there are several corollaries. The first is that nobody is forced to use or contribute to Clojure. The second is that, given that Clojure is Free Software, it's possible for someone else to pick up the baton, make a fork, and run it their own way. (egcs and XEmacs both come to mind as examples where someone did this and it wound up improving the original.... so there _is_ precedent.)
I wouldn't feel terribly bad if someone made this fork, but I'm not going to do it myself. Unlike Rich, I'm not willing at the moment to make the personal sacrifices that'd be required to make this sort of contribution. Neither, apparently, is anyone else.
So Rich gets to make the rules. Because he (and Cognitect) have paid the dues. Whether that's good for Clojure in the long run remains to be seen. (But honestly, my semi-informed take on the ecosystem is that it needs library maintenance much more than it does core language improvements. The core language has been an excellent choice for many purposes for years.)
4 replies →
I mean, he is right about open-source only being a binding license for the source, and in this case, the Eclipse 1.0 license in no way entitle users too any kind of support, decision making authority, opinion, voice, or any other such thing.
This is just fact. You can go read the license to learn more about this: https://opensource.org/licenses/eclipse-1.0.php
That part of what Rich is saying is pretty much indisputable.
The second part, is related to what is best for Clojure. And the argument is simple, Rich says what is best for Clojure is a thorough review process of all changes to its core and standard libs, with a very high bar towards contributors and their contribution. His argument is that this has worked so far, and has created the solid piece of software that is Clojure today. Thus its own success is proof that it is a good enough process and is good for Clojure.
The argument against is that contributors find it too hard and too much work and thus very little contributors make it through the process. Though I didn't really see them mention any alternative process suggestion. It seems they were mostly wanted their patch to just be merged in without challenge.
Because when you invite me to your house, I do not gain the right to demand you rearrange the furniture. You built that, you put things in their place. If I want something for it I can only make a case for it, and that case hinges on convincing you.
I don’t know this person but there’s a fork button on github. “Pressing need” —> fork
Seems to be an ego thing.
The you have to maintain your own fork. And keep up with changes upstream. And reconcile the two forks. And... And...
I'm not even mentioning the potential split in the community.
9 replies →
This is the genuine issue.
No. Whoever is leaving should have left without ranting is the only issue I'm having with this aggravating distraction. Chas knows very well how Clojure is authored. I suppose some people believe their contributions or community status give them higher authority and a right to publicly pressure Rich Hickey. But in reality they are only doing more damage to the community and likely Richs creative process on the way out. If this is the price for their contributions I want to live without them without even thinking about it.
As a power user, to me this doesn't appear to be a community issue. A handful of individuals take themselves way too seriously and don't realize how they are hurting someone emotionally.
The entire idea that a different process would produce better results is an insult in the first place. The progress and effect we got with Clojure with no enterprise funding/influence is a true miracle.
1 reply →
This thread made me look at Clojure again (it has been a few years since the last time). Searching for Bayesian inference libraries I came across this: https://github.com/cemerick/raposo
"Never, ever, ever give a talk about a library or other code publicly unless it's in a public repo prior to the talk. Period. (Exceptions to this might be things like case studies and such.) Doing otherwise is surely irritating to talk attendees, but it's even more disrespectful towards organizers, as their acceptance of your talk may have been implicitly preconditioned on the attendees being able to benefit from the code/library/project in question."
Is the expectation now that when you talk about something it is necessarily going to be open source? (And from there the expectations grow and grow...)
That quotation is prefaced as "lessons I hope to take to heart". He's not commanding everyone to do it.
7 replies →
I'm fuzzy on the details, but there's legal precedent for suing someone for reproducing your code even if they haven't copied any of it.
Otherwise its called marketing and you have to pay for it. (Not get paid for it)
1 reply →
One thing that I've found increasingly distasteful (I've noticed it in the React community, but it may be a wider trend), is the use of conference talks to announce/launch projects.
Thankfully it's still usually the case that the content of the talk is generally valuable. But ultimately, if I'm paying to fly somewhere and see your talk, I'm there to learn, not to witness your own self-promotion.
2 replies →
> 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")
- Star Wars
As a game developer: Amen!
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.
3 replies →
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.
17 replies →
If you are productive you will have enemies.
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.
2 replies →
Continuing your list:
- 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.
1 reply →
Thank you for pointing this out, there are so many niches where fans/consumers are taking the creators to task for some grievance or other.
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.
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.
To be fair, there is a difference between someone who gives away something, be it software or otherwise, and someone who sells something.
Not the same thing at all - those are commercial products. If someone has paid for a product and feels it was missold then yes, they are entitled to leave a review. Especially since cinemas don’t offer refunds to dissatisfied customers.
You know, I wrote a number of successful open source packages. By and large, feedback is positive, or at least utilitarian: bug reports, feature requests, questions. But there is also the occasional angry user, or, rarely, a simple thank you.
Recently, I published my first-ever commercial video game plugin. And was dumbfounded by the sheer positivity of the response. People thanked me! I got dozens of purely positive emails. I had never experienced such a thing in my Open Source work.
If we had more of that in Open Source, maybe maintainership wouldn't be such a burden.
I wouldn't dare writing just to say "thank you", it would feel like a no-op wasting people time. Instead, I would rather star the project on github. Did you consider those as thanks?
6 replies →
Here is a trick: don't engage with those people.
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.
Words of wisdom that truly matches yours from Tyler, The Creator: https://twitter.com/tylerthecreator/status/28567082226430771...
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?
1 reply →
Yes , it's the reality, i think it's better for the creator to learn and act to be the actual dictator. This might mean ignoring those community suggestion/request that they don't like. kinda like linus which I admire.
The attitude of many is strangely feudal: "I (potential contributor) offer my fealty (using your code) to you (author), and in exchange you owe me protection (features)." These people are under the impression that authors ought to be impressed that somebody uses their code, which is not the case. Lots of users are nothing but a weight that drags you down: if you want to swim, you must cut them loose ASAP.
This is an excellent depiction of the distinction between "free software" and "open source" as ideological frameworks. As licensing schemes, they're the same - but open source ends at the licensing scheme, as the author correctly points out. If you want to use it for a side project, great. If you want to use it to make money, great. If you want to use it to commoditize the operating system for your worldwide advertising infrastructure, great. If you want to embed it in your iOS app or in iOS itself (and the license permits doing so), great.
The free software movement, however, says things like this (from https://www.debian.org/social_contract ):
Our priorities are our users and free software.
We will be guided by the needs of our users and the free software community. We will place their interests first in our priorities.
We will give back to the free software community.
In other words, free software is about you.
I would quibble with the claim that the open-source process is what produced Clojure in the first place. The open source movement has benefited from sailing in the same direction as the free software movement and using the same tailwinds. Without the free software ethos (which was behind GNU as well as a lot of the Lisp work at MIT), would Clojure have been able to stand on the same shoulders, and would it have attracted the community of users and the ecosystem of libraries it has?
Or I would rather say... Yes, "free software" has an ideological intention, that is, to make the software free for all its users, to protect it from exploitation using a strong license, and eventually leads to some forms of social change in the software world, as in "when we have enough free software, we'll kick out those dirty licenses, ever more, hackers, ever more".
But "free software" itself is only the means to an end, it's a technical and legal tool to accomplish these ideological intentions, and as a tool, it's a collection of code published under a license scheme. When the developers served their duties by providing the source to the users, the work is done. The developers have no responsibilities to implement anything for its users.
On the other hand, if someone writes free software because they wants some forms of social change, in this sense, the intention is not solely developing free software, but to pursuit an ideology though the development of free software. And this is done by a group of people in a community, like Debian, then they must be doing whatever is needed for this goal, i.e. be guided by the needs of the users.
In conclusion, "free software" is not about you, a free software community can be, and often is about you. But it is also legitimate if it's not, in the end, it depends on the community. Some people only care about themselves, some projects just want mainly the software, but may also care about users freedom, some projects want social changes, while others focused on improving the current status of a specific technology. There are overlaps, but there are priorities as well.
I disagree. Software projects that claim to be free-software instead of opensource (plus use a "contagious" license such as GPL) don't owe you more community management than the ones with an MIT license.
Most high profile project that explicitly claim to be free software in fact do not do any kind of community management at all and do not tend to actively seek outside code contributions.
In fact the community involvement in development as exemplified by GitHub (and SourceForge before that) is to a large extent invention of the same group that started using the term open source (for what is otherwise mostly the same thing as free software).
2 replies →
I'm being a little unconventional with my terms - mostly because the article is titled "Open Source is Not About You." Zach Tellman (a prominent Clojure community member who does not work for Cognitect) just tweeted a link to his post https://medium.com/@ztellman/standing-in-the-shadow-of-giant... about "open source" and mythmaking, which is a much subtler take (and, I'd guess, probably inspired by an older flareup in the Clojure community over governance).
It is, however, the case that open source under the GPL is a perfectly well-defined concept, as is free software under the MIT license. The terms refer to worldviews about the code and ethical obligations, not to licenses.
1 reply →
Without that contagious license no one would be using Linux nor GCC, and we could all enjoy Aix, Solaris, HP-UX, Tru64, ...
This is why my code is licensed MIT. It is a gift, you owe me nothing, I owe you nothing. It might not work, it might not compile, it might delete all your files.
I could have written the same last sentences as you, but using a GPL license. No difference. Licensing is not related to this. (PS: When you choose "GPL", if someone modifies your software, they don't "owe" you those modifications; they only owe those modifications to their users, and only in case they have users. Again, no community-management here involved, just distributing the sources.)
8 replies →
If you give people someone free code and it deletes their files, you could be liable. That is why software licenses not only have permission-granting clauses but also warranty disclaimers. (Those might not protect you in every jurisdiction.)
I think you are reading too much into the term "free software" as GNU was historically[1] no less easier to contribute to than Clojure is today.
The GNU definition of free software (and the 4 freedoms) make it clear that it is about users, but only inasmuch as their private rights to do what they want on their own computers. There is no sense that openly welcoming community patches is something that is involved.
1: It's entirely possible that the community has opened up more recently, but Lucid shipped a fork of Emacs in the 80s for similar reasons to the complaints about clojure today.
This is entirely orthogonal. Free software is ideological by design. Rich here is complaining that the culture surrounding open source grew its own ideology, and that it interferes with the very process & value proposition of open source software.
Stallman's Free Software only makes the users' interests a priority when those interests are aligned with the ideology.
If the users have interests like, "I want to stick this piece of code into my proprietary program", then those interests are not prioritized.
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.
He wrote the software, he gets to have whatever attitude and tone he feels like. If you don't like it, don't use his software.
4 replies →
I didn’t read disdain at all, so I’m interested in which parts tickled your disdain detector.
4 replies →
If you want to send Rich a little bit of money, and get some swag, you can buy it here: https://clojure.org/community/swag
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.
maybe a "c-list" amendment to the licence terms?
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...
Petty.
3 replies →
Context, I think: https://gist.github.com/halgari/c17f378718cbd2fd82324002133e...
Associated Reddit thread: https://www.reddit.com/r/Clojure/comments/a0lalh/timothy_and...
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.
https://news.ycombinator.com/item?id=18534392
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.
Completely agree.
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.
From the link in geofft's comment (https://news.ycombinator.com/item?id=18538873):
"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.
1 reply →
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.
Getting responses in 24h was far from the norm for us. The responses were late and dismissive, but this was 2 years ago.
I since abandoned Clojure. I didn’t trust the core team anymore.
1 reply →
Imagine belonging to an expert, seasoned team that masters a given technique. Literally the worldwide top 1% for that technique works under your roof.
You don't take feature development lightly: each feature will be discussed and polished patiently within your team. And then you release it, for free.
Then semi-random people from the internet want to continue the discussions that were settled privately long ago, while also demonstrating this entitlement.
I guess that can be a maddening, constant stream of noise. One that cannot be dismissed harshly - you may be an expert, but definitely don't want to scare people off.
Kudos to the Clojure core team for resisting the stream in a classy, illuminating manner.
> Imagine belonging to an expert, seasoned team that masters a given technique. Literally the worldwide top 1% for that technique works under your roof.
That would worry me immensely. What sorts of things are we not realizing because we're not exposed to other ways of thinking? What sort of talent are we not training up because we don't know how to recognize it? And what do we do when some of the people under our roof retire?
Have you ever hired someone who worked at Google? They're quite probably in the worldwide top 1% for software engineering talent, and still they come out of Google expecting everything to work in a Google way. And conversely there are folks at my company - skilled software engineers - who I wish would go work at Google for at least a few months, because they've been here for probably ten years and while they're very good they've never seen how other people do things. They're skilled, but they simply have not had opportunities to learn deeply from the outside world, and in a field moving as fast as software, no single organization can keep up.
This is why open source exists in the first place. Whether or not you think there's an ethical imperative to share software, the whole idea of open source is that different companies can share source code to produce better results than in-house development and buying licenses to closed-source software would achieve. At some point, if you're on an expert team that works under one roof, you're going to stop being the experts in the thing, because the other 99% of people interested in the subject can all learn from each other, can try the things you dismissed privately long ago, can experiment at scales you simply couldn't imagine.
yeah, thats important, but its also not whats happening here. This is an argument between people who've contributed a great deal to clojure and clojures ultimate authority. Which is completely different then entitled randos drive-by commenting and demanding accommodation.
I haven't used Clojure much but what I hear is mostly great. And I love this rant, its always refreshing when people speak their minds.
But.... Rich is pushing things a little too far I believe.
On the front page of the Clojure web site, under the section 'Rationale", his very first 6 words are:
> "Customers and stakeholders have substantial investments [...]"
Those words do not sit well with (from the rant):
> "[..] you are not thereby entitled to anything at all. You are not entitled to contribute. You are not entitled to features. You are not entitled to the attention of others. You are not entitled to having value attached to your complaints. You are not entitled to this explanation."
I get it, Rich is making a point, and its a fair and unarguable one - if he indeed has no loyalty or feeling whatsoever towards said Customers and Stakeholders.
But in the real world, we want our work to be valued by others, and I'll bet that the stewards of Clojure feel just the same and maybe shudder just a little.
Rich Hickey stands for good design. That means saying "no" to a lot if ideas that are good, but not part of the vision, and it means not running experiments on your users in the main releases. Whether he reaches that ideal, I dunno, but he lays out the vision pretty clearly when he speaks. It isn't the only way, but it is Clojure's way.
When he talks about customers and stakeholders, he is talking about people who have bought in to that design. It is very easy to support his position here. Rich knows exactly how he wants to program and the man is a visionary of data-driven programming and thinking. If you don't like that vision, maybe don't use Clojure and find a different lisp.
Great design is a very foreign idea to a lot of mainstream software developers - most of them, sooner or later, go for the "big rewrite" because they didn't get the design right to start with. Things like Python 2 -> 3 spring to mind (breaking changes to print! whoever thought that was a good idea didn't respect the language users). With that rational, he is promising not to do exactly what the Python people did.
There is a big difference between design and bug fixes. There are many small tickets with bug fixes already written that have not been merged into Clojure citing Rich’s time. Sometimes months or years go by, even when the Jira thread includes supporting comments from Alex Miller at Cognitect. Small fixes that improve the language without altering its design, making core functions more stable with edges cases, and they never make it into the language.
3 replies →
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?
Loyalty and valuation are not equivalent to entitlement.
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.
Be careful what you wish for... you just might get it.
Forks are not particularly fun from the user's standpoint.
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.
1 reply →
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.
More choices are almost always preferable over a long enough time frame.
Writing negative comments/tweets is a helluva lot easier than staking skin in the game.
> 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.
Thank you, Rich.
I run a few OSS projects, among which one with 10k+ github stars that has a decent size community. While I recognize my own personality in Rich's post ("if you don't like my direction.. there's the door") for some reason I ended up running this project with the attitude that everyone I am interacting with their time, insights, and needs are just as important as mine. It's been very refreshing. It makes people very eager to contribute, and there's close to 0 hostile behavior in the community. It really works magic.
I have no doubt that Rich's time and his direction of Clojure are endlessly more important than the average community member, as a fact. But you CAN'T communicate this way! Interacting with someone where before you start there is the assumption that someone is way more important cannot result in a good interaction. Even if it is a fact, even if both people involved know it, you will be much better off if you act like it doesn't exist for the purpose of communication.
Of course, time is limited, but I find there is an art to giving short reactions that are still respectful in this way. And it is not like Cognitect entirely does NOT want there to be community interaction (like Rich himself says), so it is just a question of optimizing these interactions.
It still boggles me that Jira tickets with small bug fixes to real problems confirmed by other members of Cognitect have never been merged, due to Rich’s time. Simple fixes to core functions that make the language more stable for edge cases without breaking design or backwards compatibility. Fixes that the Jira threads reveal others at Cognitect support patching and for which patches have already been written. Tiny fixes with little code involved. I understand being conservative on new features but isn’t it in everyone’s interest, including Rich and Cognitect’s, to fix actual bugs?
The answer tends to be that if the bug doesn’t affect Rich personally then it does not get attention. That doesn’t seem healthy for the language.
Is this true? I've never personally been affected by a bug, and every new versions has a list of bugfixes that were merged in.
I think most of those fixes you mention are actually semantic altering and thus possibly backwards incompatible.
We actually never got our bugs solved. My particular favorite was CLJ-1741, which made reloading code with Cursive basically not work in our code base. Opened in 2015, effectively abandoned to its fate in 2016.
1 reply →
I see Github playing a big role in bringing about this situation. The collaboration model focuses on the "who" of software development and not the "what". It used to be people were concerned about making a piece of software that did something interesting. Now it's all about how many stars, forks and followers you can get. Github made it too easy to "collaborate" and now you see any number of non-developer interlopers pushing project owners around. There needs to be a new model that's not so focused on the social but is focused on the tech and just the tech.
He is correct that open source developers don't "owe" anyone anything. But this is kinda missing the point.
The point is that if you have a bad development process, people are going to have issues. And these issues are real.
Even though you have no "obligation" to solve these problems that you have created for other people, you shouldn't be surprised if people bring them up, or perhaps even fork the project with a bunch of other people who also have problems with you.
Sure, the community does not own your time, but neither do you own the community. A community is fully within it right to do something else with their time, or convince other people to contribute to a different project.
> Even though you have no "obligation" to solve these problems that you have created for other people...
Publishers of open source code don't create problems for other people. People who accept that code into their projects assume those problems for themselves.
If an open source package has bugs in the forest and nobody is around to install it...
This attitude is just an excuse to hand wave away genuine criticism of shoddy engineering.
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.
I believe your last two paragraphs are exactly what he's suggesting: complainers are free to fork and work on a better process if they're so inclined.
In his post he stated as follow:
> 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 reply →
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.
Fyi... his post today seems to be related to a previous reddit post that HN also discussed: https://news.ycombinator.com/item?id=15425632
(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.)
Broadly yes, but I'm guessing this one was sparked by this thread https://groups.google.com/d/msg/clojure/2GQQpxNcDlM/St3Can2x... and the indignation that spilled out elsewhere. We get these little brouhahas every couple months o_O
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.
3 replies →
I haven’t used Clojure much in the last two years, but this is the part I remember is most surprising, and completely congruent with what Rich describes. You hear about this thing, it is a Lisp, and you wonder if it might be some edgy thing, moving fast, breaking things, showing off this mighty power (that Paul Graham wrote about) of Lisp.
And it is a little bit of that; but it's also a lot more of an intentionally conservative, even boring, extremely practical tool for building real things in a concise manner. In this way it fits into the Java ecosystem well, alongside many other very boring, robust, proven, reliable chunks of code.
Much of my work today is in the Node/NPM/JS ecosystem; although that has its advantages also, some days I really miss the boring reliable conservatism of Java and Clojure!
I would argue that if you release an open source project, you do have a responsibility to communicate enough about your intentions that potential users can base their expectations accordingly.
That doesn't have to be at any particular level. But if a project is unmaintained... why not tell people? If you are sharing a project in case it's useful to someone but don't really intend to deal with any external bug reports or feature requests at all... why not just clearly advertise that?
Nope, you're not entitled to anything. A license is just a license. You're free to use the code. If the releaser gives you no communication about expectations, then it's your choice to use it or not. They're obligated to give you anything, not even the time of day. Enjoy your free code, or don't.
And yet, _most_ people have some interest in treating other people respectfully. Which is the only reason the open source ecosystem works at all.
Although there is of course no warranty, I think it's fair that when projects have marketing websites saying how great they are and encouraging widespread use, users can complain when the software isn't fit for use.
If you're going to be strict about how you don't owe anyone anything, it might be a good idea not to undermine that message in your marketing. Better to tell people all the reasons why they shouldn't use your code. Not for production! There may be bugs that you have to fix yourself!
And then work with developers who don't scare easily.
This post is absolutely correct. All your entitled to (if anything) is the code, as is.
You're not entitled to:
* Community engagement
* Bug fixes
* Timely pull requests
* Anything else
You get the code as it has been released. Whatever you do with it is up to you. The finished product you build using the code you have found is your responsibility and yours alone.
My personal favorites:
> Open source is a no-strings-attached gift
> Morale erosion amongst creators is a real thing.
It reminds me of a project called aurman [1] (a great AUR-Client for Arch Linux). Due to the 'feedback' from the community, the main author went from loving to work on his project to hating it. In the end, he stopped the public development to protect himself from the negativity.
[1] https://github.com/polygamma/aurman
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.
Yeah and it takes a company the scale of Google to maintain it. Not feasible for pretty much anyone else.
1 reply →
People are inherently selfish. Everyone is looking to better their own self-interests, seek validation, and seek attention in life. A community - any community - is made entirely of these people.
An effective leader is one who can play to the strength of this fact rather than fighting it. You have thousands of people willing to spend their time for you. How can you make their interests align with your own? How can you convince them that your self-interest is their self-interest?
Funny, but I don't think calling people entitled is the answer to this.
I maintain a few open source projects that many developers use (along with many more projects that no one uses) and I get like one PR a month. It seems like some developer’s entire workflows depend on some of the tools and libs I maintain, but I don’t even use the damn things myself.
That seems like the perfect case for self interest: make this thing you use all the time work better for you. The code is usually fairly clean and the contribution process documented. And yet all the help wanted issues just sit there.
How have other maintainers been able to encourage more valuable community contributions?
I'm not a member of the Clojure community, and have no idea what context may have driven this but...
...I agree with his point 100%, and it's certainly relevant to other communities.
Check these other comments
https://news.ycombinator.com/item?id=18538298
Could it be that people who use your OSS think you have an obligation to them, because you marketed your software in a nice and pretty gift wrap package (eg. web page) and they chose yours over and alternative (ie chose to invest their time and effort on it)? They chose to "fall" for your marketing over that of another project.
Maybe they feel that by choosing your software over an alternative, they're also helping you (since it's your project after all) and they atypically expect some things of you?
P.S. I'm not taking sides. This is just a shower thought.
Although I appreaciate almost all opinion articles and videos posted by Rich, what I read here is that Rich seems to see his project about himself which fits his previous behave as Clojure's Dictator For Life. In other words, he could never remove himself from the equation or make clojure an independent long standing self directed project.
In general terms of OS project, I think the first premise is already flawed. What if there were open source projects meant to satisfy their users or public? Or just iwth very different goals than yours? Do you even think that software is just finished when it is released? that fanbase should be allowed? What if Rich itself is the main bottle neck for his own masterpiece?
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.
Well the code is free but the clojure trademark is his.
> 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!
For those asking about context, or what brought this on, I imagine it wasn't any single complaint or event.
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.
It's painful how many people don't seem to think this way. If you've ever contributed a patch to an open source project, do you think you should be obligated to maintain this patch for the foreseeable future? If the answer to that is 'no,' then why would a greater contribution, such as an entire project, be held to such obligations? It's disappointing.
A decade ago I found Rich's way of communication tough to swallow and borderline abusive, but re-examining it with the acceptance the years of using probably the most expressive and versatile language on the planet I find it refreshingly clear and to the point. And he's absolutely right of course, his time is just that, his time.
Arguably the best and most important thing an open source author can do is engineering their code the way as easy to understand and extend (this doesn't mean an over-engineered architecture, quite the opposite) as possible so whoever wants something particular could really easily add/change it with an extension or by forking and editing the core code. This done you can really legitimately direct those asking for what you don't feel like doing to do it themselves. Another great idea, IMHO, is hosting issue tracking on GitHub and making it the only accepted channel for feature requests and bug reports.
Making github the only accepted channel for anything is hardly a great idea. Perhaps if you used "an additional" instead of "the only" in that sentence...
I believe this way people are more likely to be reasonably self-moderating and specific and less likely to engage in personally emotional argument with you than if you use e-mail. It will also give people convenience of filing a bug/suggestion without having to register on yet another bug tracker given they already have a GitHib account (who hasn't?). Needless to say using a single bug tracking system and input channel is much more convenient for everybody than if there were many.
"If the way Clojure works isn't for you, a process which produced Clojure in the first place, paradoxically, so be it"
The best conclusion :)
> 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.
1 reply →
I'm thankful for Clojure; it's brought a lot of joy into programming for me personally.
What's the context here?
Customer service is hard. When you aren't paid for it, it is very frustrating. It often manifests as anger from open source contributors.
If I'm forced at work to work with mediocre FOSS stack without support culture (even for paid tiers), it is about me. I'm not choosing to work with a subpar farce of a technology like npm, it's forced upon me.
That has nothing to do with open source, but with your relationship with your employers.
Oh look, a philosophical essay disguised as a series of self-evident truths.
"All social impositions associated with it, including the idea of 'community-driven-development' are part of a recently-invented mythology..."
Reminds me of Margaret Thatcher saying "There's nos such thing as society." https://www.theguardian.com/politics/2013/apr/08/margaret-th...
Now if only they can get someone to keep repeating it, it'll be true.
Come on.
Related: https://news.ycombinator.com/item?id=18538614
Do not agitate. Open Source is only part of the business model.
Seems relevant to the event-stream fiasco from yesterday.
I'm not a user of Clojure, but I'm a user of other FOSS tools (Docker) for which I've had complaints.
Though I have potential issues here, I think it is important that this be said. It highlights missed expectations. This open source thing is a weird new(ish) world, and we need to be on the same page. It's been a few decades, but perhaps we haven't quite adjusted yet. Or maybe this hippie thing actually doesn't work, which would be a real shame.
The fact is that we rely on it. And I think that this really is an alternate mode of creation. I could be wrong but I don't think the idea of "community development" is something that was recently made up. It's part of the Free Software ethos. Perhaps what is new here is a notion that there not be a party at the top of each fork who has ultimate responsibility.
A pure gift, take it or leave it, no strings attached in either direction, is fine, and should be appreciated. But it's useless to users who need to rely on what you've produced. If the project is not subject to the demands of its users (which includes contributors, to the extent that they are users with demands that they are willing to fulfil themselves) then it's got a serious disadvantage over commercial software without a free distribution model. It's not akin to a serious tool for sale. And _if that doesn't meet expectations_, people are within reason to push back.
The other side of it is that there have to be limits, of course. There has to be respect for the producer, their time, their preferred mode of management, the limit of the scope of the project, etc. There have to be judgement calls made, just like commercial software without a free distribution model, as to what does and doesn't make it into the project. For all these reasons I can see that it's important that a producer pushed back here.
But if the producer doesn't voluntarily take on some level of responsibility as part of running the project, whatever the terms may be, then at the end of the day the project can't be relied on within the economy. This is not a demand on the author of this post. He is entitled to treating Clojure under whatever terms he wants. But somebody has to, for it to work in our system.
I think the solution is just better messaging of expectations. What this project is. What expectations should you have as a user. What expectations should you have as a contributor. Now we can all look at it as a reference point, and decide: Do we want to rely on this? Do we want to spend our time working on this? Do we have a basis for complaint?
Really, this is the same set of questions that are answered in any business arrangement. Perhaps there needs to be a SOCIAL_CONTRACT file next to LICENSE, README, etc.
I think if you are doing an excellent job with your project, noone has time for you[dev] , as they are too busy enjoying your project. its like when granpa tries to get in on the basement gamefest with the kids. let them play, your best contribution is to make more toys for them to play with and let come to you and ask for more.
I like this reddit post by rhickey regarding entitlement: https://old.reddit.com/r/Clojure/comments/73yznc/on_whose_au...
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?
This one I presume https://news.ycombinator.com/item?id=12906119
As an open source developer, this guys seems like a complete asshole.
Yeah, Rich is obviously right. Concerning Clojure, or any Lisp variant for that matter, I came to realize that the cost of the unusual prefix notation -- which does cause inconvenience to people trained on using infix -- needs to be offset by the usefulness of defmacro, i.e. the possibility of using macros. Paul Graham insists that it is surely worth it, but unfortunately, he does not show convincing examples. So, I keep sitting on the fence. I am ready to be convinced, though, with compelling examples of a problem that I cannot possibly solve with defun and for which I would need defmacro.
> that I cannot possibly solve with defun and for which I would need defmacro
Well, defun is a macro: http://clhs.lisp.se/Body/m_defun.htm
The parenthesized prefix notation is advantageous because it is unambiguous and easy to format. People trained on infix still make mistakes due to associativity and precedence: mistakes in understanding an expression and in writing the correct expression which matches their intent. Their skill does not translate into unfamiliar languages that have unfamiliar operators with unfamiliar precedence and associativity rules.
The user of a Lisp benefits from the development which has gone into the language/implementation. That development is lubricated by the structure of the code. The Lisp programmer does not only write new macros, but uses existing ones, either in the language/implementation or third party libraries.
There is no problem you cannot possibly solve with defun (plus escape hatches to access any aspect of the host environment), because defun gives you access to a Turing -complete computation model.
This is simply not a genuinely honest way to evaluate tools. Gee, I'm not convinced that there is a text editing problem I can't possibly solve with ed if I bash at the keyboard long enough; so for now I will keep sitting on the fence.
possibly isn't easily, efficiently, maintainably, and so on.
> Paul Graham insists that it is surely worth it, but unfortunately, he does not show convincing examples [of the usefulness of macros].
Seriously? Are you suggesting On Lisp contains no convincing examples? It's what the whole book is about.
I think that programmers would generally be willing to overcome the inconvenience of the unusual notation, if the advantage of using defmacro was obvious from good examples to which they could, at least, relate. This question was also asked on stackoverflow: https://stackoverflow.com/questions/267862/what-makes-lisp-m.... My opinion is that the examples in the answers are neither obvious nor compelling. Hence, I am still waiting for better examples.
I'm guessing that this is a response to the current trend towards Codes of Conduct, which are best understood as part of the Long March through the Institutions, a politicization of things that aren't inherently political.
It's not, it's about the entitlement of many users of open source projects.
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.
>> 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.
Taking this into personal attack breaks HN's civility rule. Please review https://news.ycombinator.com/item?id=18538285 and marked it off-topic.
Rich is well compensated mostly because he's a brilliant developer and architect: Clojure is just one point of evidence towards that fact.
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.
You however don't get to influence _my_ recipe.
That's just your empty entitlement of "he should share his toys with me more" under the guise of "F/OSS" and, uh, being a "good citizen" or something.
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.
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.
Please don't create HN accounts to do that with.
Rich Hickey needs to stop poking people in the eye with a stick.
> You are not entitled to the attention of others. You are not entitled to having value attached to your complaints. You are not entitled to this explanation.
This could be handled much more diplomatically. What he's saying here is "fuck you and your needs". Opportunity cost waits for nobody, but taking a second to not provoke people is a good idea.
> We at Cognitect have to show up to work, every day, to make a living. We get no royalties of any kind from Clojure.
Ditto for the people who wrote open source libraries, some that are critical for Clojure's adoption. In fact they typically did this after working a 9-5, rather than during it.
> To be honest, I could use that money in my retirement account, having depleted it to make Clojure in the first place.
"Look how much I've suffered for you!" is about as effective for leadership as it is for parenting.
> But kindly don't burn the community down on your way out, with self-serving proclamations.
That's a nice "fuck you" to frustrated developers. "Shut up with your complaints and go away" is a bad community management technique.
What's next, people who sell cars aren't responsible for making sure they're safe? People who sell food aren't responsible for whether it gives people food poisoning?
If you release a product then at the minimum it's your responsibility to make sure it's not going to harm others. If you can't do this then you shouldn't be releasing open source software.
Adding a disclaimer at the bottom doesn't absolve you of gross negligence.
"Sell" is a pretty important word there. There are laws and regulations for those, and neither comes with an explicit license saying something like "disclaims all warranties and conditions, express and implied, including warranties or conditions of title and non-infringement, and implied warranties or conditions of merchantability and fitness for a particular purpose."
> neither comes with an explicit license saying something like "disclaims all warranties and conditions, express and implied, including warranties or conditions of title and non-infringement, and implied warranties or conditions of merchantability and fitness for a particular purpose."
Because they obviously would be not legally binding. Again, you can't absolve yourself of gross negligence any more than you can sell yourself into slavery. And legally speaking, selling something almost always includes giving that thing away for free. (Except for in a few cases where gifts are specifically exempted, like for some low-level drug crimes at the state level.)
Well, the license specifically says they aren't responsible for negligence and to use the software you have to abide by the license so...
Companies don't care about making products safe until government steps in and forces them to. Unsafe food was not "next", it was the norm until Upton Sinclair wrote The Jungle. Unsafe cars are not "next", they were the norm; seatbelts were first recommended by a surgeon in 1930 who went on to form the Automobile Safety League of America, they weren't mandatory until at least 30 years later with seat belt legislation [1], or airbags legislation in 1998 [2].
Remember .. cigarettes? Arsenic Wallpaper and cloth[3]? Radium cosmetics [4]? Toasty warm Radium blankets[5]? Shoe fitting x-ray fluouroscopes[6]? Lead water pipes[7]? Sugar? Guns? non-fire resistant household furniture? Dinitrophenol[8]? Asbestos? Leaded petrol? CFCs? Unsafe buildings? Bisphenol-A? BSE related beef? 3D printers and their carcinogenic particle side effects[9]? Trans fats[10]?
and then why we have things like the CE marking safety standard in Europe. On and on, products are harmful by default until government steps in and forces manufacturers to make them safe(r). The free market cares about profit, not people.
What's next, people who make products are responsible for making them safe?
[1] https://en.wikipedia.org/wiki/Seat_belt_legislation
[2] https://www.history.com/this-day-in-history/federal-legislat...
[3] https://hyperallergic.com/329747/death-by-wallpaper-alluring...
[4] https://www.atlasobscura.com/articles/objects-of-intrigue-lo...
[5] https://www.sciencephoto.com/media/364732/view/radium-blanke...
[6] https://gizmodo.com/the-insane-cancer-machines-that-used-to-...
[7] https://www.ncbi.nlm.nih.gov/pmc/articles/PMC2509614/
[8] https://www.theguardian.com/science/the-h-word/2014/feb/06/d...
[9] http://blog.ichibanelectronic.com/3d-printers/3d-printers-ca...
[10] https://en.wikipedia.org/wiki/Trans_fat#Public_response_and_...
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.
You're conflating "Open Source" with FOSS.
FOSS is the mantra of a particular community-oriented software-development zeitgeist, where things are developed by a community, without a project maintainership per se—i.e. where "the project" refers to whatever the most active fork of the project is, rather than to the project as maintained by some particular BDFL.
FOSS projects are usually maintained under the aegis of one or more software foundations, like GNU or the ASF.
"Open source", on the other hand, means exactly what it says. Microsoft does Open Source. Apple does Open Source. Oracle does Open Source. It means exactly as little as the image conjured in your head by that list.
It's not that simple. Open source projects, including Clojure, benefit from the community through bug reports, documentation, free user support, articles, etc.
To make it as simple as you suggest, there should be a code repository and nothing more. I don't think that's the case in the majority of open source projects or even what Clojure desires.
That being said, if you're not contributing back to a project (in any sensible way, not just code) maybe you should tone down your demands. I completely sympathise with author but things are a bit more complex in reality. Ignoring the benefits of these interactions/contributions is not fair to the rest of the community that is contributing. Maybe the author does that feel that's currently enough? I can totally relate.
FOSS is just "free and open source software" - a catch-all for both camps to avoid offending anyone. It doesn't imply any particular development methodology or project maintainership.
I do not think it's fair or correct to confine Open Source to that definition the last paragraphy of your comment implies. It may only be a subset of Open source. ASF itself defines what it does as Open Source.
What's described in this rant is basically "Source Available". Open Source means more than that, per ASF, per OSI, and per many who publish software under non copyleft licenses.
I've never read anything that supports the claim that licenses have anything to do with the actual development process.
Please stop claiming authority over a descriptive term of open source. Nobody has authority to define open source.
I did not do that anywhere, especially in the comment you're responding to. It's Hickey who attempts to make such claim, not me.
1 reply →
> 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.
> you should feel bad
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
1 reply →
> you should feel bad
> 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.