
Open Source is Not About You - jashkenas
https://gist.github.com/richhickey/1563cddea1002958f96e7ba9519972d9
======
newcrobuzon
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](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.

~~~
hoaw
> 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?

~~~
mschaef
> 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.)

~~~
PhasmaFelis
> _Because Rich has the rights to do what he wants with his time and money.
> (Like everybody else.)_

This feels like a non sequitur. Having a _right_ to do something is completely
orthogonal to whether you _should_ do that thing.

~~~
mschaef
> Having a right to do something is completely orthogonal to whether you
> should do that thing.

Yeah... there are really several conversations that could be had:

1\. Rich deserves credit and respect for personally taking on a cost that
ranges into the hundreds of thousands of dollars to fund Clojure. Very few
people do this, and even fewer bring the taste and judgement Rich brought to
Clojure.

2\. Rich/Cognitect currently own the Clojure governance model and they can do
with it what they want.

3\. Maybe the current governance model isn't what's going to bring Clojure the
next 20-30 years of viability.

My take on it essentially this:

1\. Yes. I wouldn't/couldn't do it myself. (And I've started down the path at
least once.)

2\. Yup. Maybe it will be what the platform needs to grow and thrive. Maybe
not. Maybe it will be attractive to users and developers. Maybe not.

3\. At some point, this will probably be true. Given the history of companies
and projects, this shouldn't be a surprise.

------
Isamu
> 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.

~~~
madrox
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

~~~
georgeecollins
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.

~~~
Faark
Then you better stick to that classical sales model that seems to be on the
way out. The minute you sell the full package of an unfinished products,
people will feel entitled to what they expect it to be (rightfully, imo). So
you'd should avoid Pre-Purchase, Season Pass and some degree Early Access. I'm
torn about the latter, since it is supposed to be sold "as is" with no
expectations, but don't think this is was most actually do.

Also how do you think about post launch updates to fix bugs? Those seem to be
generally expected as well, now.

~~~
btschaegg
> Also how do you think about post launch updates to fix bugs? Those seem to
> be generally expected as well, now.

Personally, I'd say the consumers are entitled to those, too. Your comment
made me think of various games where I think that wasn't the case -- and
that's mainly because those games were _finished_ (and polished) before
release.

I never expected any bugfixes for Games such as Starfox 64, Zeldas, Super
Marios, and various others out of my old SNES and N64 cartriges. Because they
worked. They were finished. Funny enough: Super Mario Odyssey had some a-ha
moment for me because it also worked just fine literally out of the box, which
is something I'm not seeing often enough anymore.

But honestly, launches nowadays are usually far more on the side of Games like
Elder Scrolls: Oblivion than those examples.

Imagine a regular software engineer in $MARKET going "ugh, all these people
we've sold buggy software to at full price now think they're entitled to
bugfixes."

OTOH, there are of course some games where the effort put in by the developers
far exceeds what any customer could reasonably expect. Terraria would be a
great example for this.

------
geofft
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](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?

~~~
knocte
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.

~~~
dfox
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).

~~~
xiphias2
The software that allows the GitHub style (light-forking) environment is
called git, created by Linus. He's a great example of a person who doesn't
care about free software ideologies, but cares about open sourcing code a lot.

~~~
toyg
And still, both his main projects (Linux and git) are under the most
“ideological” license, the GPL. And the troubles he’s gone to, in order to
keep this state of things in the face of commercial pressures on Linux, are
almost biblical.

Linus cares a great deal, he just doesn’t want to be cornered as an FSF
zealot.

------
conceptpad
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?

~~~
brianpgordon
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.

~~~
marcus_holmes
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.

~~~
brianpgordon
I took what I see as a moderate position lightly criticizing his tone, but
because you're going way farther than that and asserting that he can be as
much of a jerk as he wants, let's address that argument.

I think it's nonsense. Rich is probably among the most brilliant software
engineers on the planet but that has no bearing whatsoever on whether he needs
to be polite and show human empathy and decency like everyone else does. You
can be toxic and hostile and people will put up with it if you're useful
enough (c.f. Linus) but we shouldn't be lining up, comment after comment after
comment, to cheer that kind of behavior on.

Again, I don't think this is a big deal. I think that his rant is just a small
indiscretion and we're all human, but I'm dismayed to see such an outpouring
of support for exactly the position that you're putting forward. What I'm
saying isn't "nauseating PC culture" as one GitHub commenter put it; it's just
_not being an asshole_.

~~~
gizzlon
I found the original rational, useful and straight-forward. It's not an
"indiscretion".

So, yeah, your comments are approaching "nauseating PC culture" because you
can't read something like the original without being offended some how.

------
lgessler
Context, I think:
[https://gist.github.com/halgari/c17f378718cbd2fd82324002133e...](https://gist.github.com/halgari/c17f378718cbd2fd82324002133ef678)

Associated Reddit thread:
[https://www.reddit.com/r/Clojure/comments/a0lalh/timothy_and...](https://www.reddit.com/r/Clojure/comments/a0lalh/timothy_and_stu_on_why_its_hard_to_contribute_to/)

~~~
WestCoastJustin
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](https://news.ycombinator.com/item?id=18534392)

------
elihu
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.

~~~
spiralganglion
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.

~~~
didibus
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.

------
vemv
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.

~~~
geofft
> _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.

------
abraae
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.

~~~
another-one-off
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.

~~~
hellofunk
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.

~~~
purple_ducks
quoting _halgari from June 2016(on
clojure)[[https://news.ycombinator.com/item?id=11884028](https://news.ycombinator.com/item?id=11884028)]:

> Something that is often very hard to understand (it took me years to do so).
> Is that maintaining a language is insanely hard. Everything has a cost. Let
> me give a good example: A few years back someone submitted a patch that
> improved the error messages in Clojure. Worked great, just a single extra
> "if" and a message. It was committed to master. Then people's code got way
> slower. Why? Well this was a often used function and that single if blew the
> JVM inline budget causing that function to never be inlined. And that
> improvement had to he yanked out.

~~~
hellofunk
That’s a new feature. I am talking about _bug fixes_... I reiterate: big
difference.

~~~
purple_ducks
a code change is still a code change.

------
drcode
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.

~~~
jeffdavis
Be careful what you wish for... you just might get it.

Forks are not particularly fun from the user's standpoint.

~~~
SwellJoe
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.

~~~
davidscolgan
This is why I've never worried about anyone stealing my ideas or code. The set
of people who could both actually have the ability to pull off forking
something and running the project, and have the motivation to see it through,
is so vanishingly small as to be non-existent.

------
mschaef
> 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.

------
Aardappel
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.

------
hellofunk
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.

~~~
didibus
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.

~~~
village-idiot
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.

~~~
didibus
Well, I mean, it's still open. I'm sure if it got more votes on it, it would
be better prioritized. That said, I guess this is a good example of a possibly
starving issue where the core team can't scale to address the most minor
issues.

------
malvosenior
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.

------
stale2002
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.

~~~
slig
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.

~~~
stale2002
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.

~~~
yarrel
By this logic you are making the same mistake as both.

------
jasode
Fyi... his post today seems to be related to a previous reddit post that HN
also discussed:
[https://news.ycombinator.com/item?id=15425632](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.)

~~~
gw
Broadly yes, but I'm guessing this one was sparked by this thread
[https://groups.google.com/d/msg/clojure/2GQQpxNcDlM/St3Can2x...](https://groups.google.com/d/msg/clojure/2GQQpxNcDlM/St3Can2xAgAJ)
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.

~~~
jasode
_> 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.

~~~
sanxiyn
> Maybe Hoare left years before the Rust community could turn on him and
> accuse Mozilla of holding back progress in the language

Yes, this is the case. (As far as I can tell.)

~~~
steveklabnik
You're downvoted, but I think that's a bit unfair.

Graydon did leave pretty early, so there wasn't this kind of pressure yet,
really. However, after he left, we moved to a "core team" model, which meant
that a few people (I among them) were the decision makers for everything. This
eventually lead to complaints and pressure, and we opened it up further from
there, adding all the other teams.

------
jrochkind1
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?

~~~
VogonWorkEthic
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.

~~~
jrochkind1
And yet, _most_ people have some interest in treating other people
respectfully. Which is the only reason the open source ecosystem works at all.

------
howeyc
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.

------
skybrian
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.

------
arendtio
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](https://github.com/polygamma/aurman)

------
softwaredoug
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.

~~~
toast0
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.

~~~
softwaredoug
Yeah and it takes a company the scale of Google to maintain it. Not feasible
for pretty much anyone else.

~~~
icebraining
Few small companies can maintain a full OS, regardless of the open source
alternatives. Yet FreeBSD, OpenBSD and SmartOS are all still living projects,
and none have a Google behind them.

------
pubby
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.

~~~
mattbierner
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?

------
Lazare
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.

~~~
O_H_E
Check these other comments

[https://news.ycombinator.com/item?id=18538267](https://news.ycombinator.com/item?id=18538267)

[https://news.ycombinator.com/item?id=18538298](https://news.ycombinator.com/item?id=18538298)

------
nudpiedo
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.

~~~
type0
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!

------
FPGAhacker
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.

------
jchw
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.

------
lbj
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.

------
qwerty456127
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.

~~~
pferde
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...

~~~
qwerty456127
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.

------
dudul
"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 :)

------
jancsika
> 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.

~~~
zapzupnz
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.

~~~
jancsika
> 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.

~~~
zapzupnz
> there is usually immense pleasure in creating and controlling a project

I think this is the part of a larger myth against which the writer rallies.

The joy is not in maintenance and control. The joy is in working with like-
minded peers who share a vision, the joy is in designing and implementing an
outcome that does what one wants it to do, the joy is in being able to share
it.

The mundane activities associated with that are not joy. That's just work, not
pleasure. Those aspects of project management are means to an end, not the
actual end.

> I can't send a patch to ostensibly improve the hardware (or even software)
> of an iPhone. [...] developers presumably complaining about low patch
> acceptance and long wait times

Rich said that the sorts of patches people were submitting were of low quality
and didn't fit the overall project vision. Then people were getting upset
because their amazing patches weren't being accepted there and then. Frankly,
that's not a community I'd want to foster nor be in charge of. Nobody should
want that.

I don't see any conflict at all with a statement along the lines "I am the
leader of this project, this is my baby, and I have sunk a lot of my time and
resources into it" next to "I'm not accepting your pull requests and patches
willy-nilly just because you complain a lot".

------
umanwizard
What's the context here?

------
pasxizeis
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.

------
mmaunder
Customer service is hard. When you aren't paid for it, it is very frustrating.
It often manifests as anger from open source contributors.

------
elwell
I'm thankful for Clojure; it's brought a lot of joy into programming for me
personally.

------
_pmf_
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.

~~~
icebraining
That has nothing to do with open source, but with your relationship with your
employers.

------
8bitsrule
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...](https://www.theguardian.com/politics/2013/apr/08/margaret-thatcher-
quotes)

Now if only they can get someone to keep repeating it, it'll be _true_.

------
kazinator
Related:
[https://news.ycombinator.com/item?id=18538614](https://news.ycombinator.com/item?id=18538614)

------
zekiunal
Do not agitate. Open Source is only part of the business model.

------
kompy
Seems relevant to the event-stream fiasco from yesterday.

------
orblivion
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.

------
cruella_deville
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.

------
wild_preference
I like this reddit post by rhickey regarding entitlement:
[https://old.reddit.com/r/Clojure/comments/73yznc/on_whose_au...](https://old.reddit.com/r/Clojure/comments/73yznc/on_whose_authority/do1olag/)

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.

~~~
dymk
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.

~~~
Lazare
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?

------
core-questions
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.

~~~
mhluongo
It's not, it's about the entitlement of many users of open source projects.

~~~
zapzupnz
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.

------
village-idiot
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.

------
neokantian
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.

~~~
kazinator
> _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](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.

------
Alex3917
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.

~~~
lvh
"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."

~~~
Alex3917
> 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.)

------
gkya
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.

~~~
derefr
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.

~~~
gtirloni
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.

