@MatejLach That seems to be an answer to a twitter thread from an ex-clojure contributor (https://twitter.com/cemerick/status/1067111260611850240).
Which honestly makes it kind of moot, because it's not about users. You do owe contributors! They made your software better, so maybe just try to make that part easy for them?
And this idea that patches will be rejected after years sounds awful. I mean rejecting patches happens, but the earlier that happens the better!
This makes me really not want to contribute to clojure.
@hirnbrot Agreed! I think that he's wrong somewhat even if you accept his premise of mere "users", but not acknowledging fellow contributors as more than "users", (not that there's anything wrong with being one), stenches of a huge ego.
Moreover, we're talking about a programming language here. A large percentage of these users probably wrote a library or two at some point, thus certainly contributing to the "ecosystem" if not to the language itself. Without an ecosystem, languages are dead.
@MatejLach One additional thing here is that the process seems to just be wasteful.
Apparently the way it works is that there's a middleman, who occasionally gets to speak to the BDFL on high, and so simple discussions just drag on for months instead of minutes.
That just seems like an inefficient use of everyone's time, because of the context switching and long delays, which mean everyone has to get back up to speed.
Even if you don't plan on addressing the issue, respecting people's time seems like the minimum you could do.
There's a reason that companies who ignore job applicants for weeks at a time have a bad reputation.
And forking is not a great solution! If Hickey is as brilliant at design as the comments on HN and elsewhere state he is, then not having him involved is a terrible waste.
If the process is as awful as it sounds, I'm flabbergasted as to why it couldn't possibly be fixed, since it just seems to waste _everyone_s time.
Also I'd like Hickey to see that contributors _matter_, and that responding promptly is important!
But if you actually need the software, then forking might be the worse option, even for you. If you can't keep up with upstream, then the changes you can't get in there might not be worth it.
It also means more work for e.g. distributors, who need to pick a side, and with dependends.
See e.g. the ffmpeg/libav mess, or Libreoffice vs OpenOffice.
a) That's what an scribe from Ancient Egypt would say about people being able to read and write. The fact that #Informatics (or #ComputerScience, if you prefer) is so #primitive that it can be used to gain power, doesn't mean that it's will never progress.
b) More forks, more roads explored, more lesson learnt, more curious minds challenging such lessons, more progress for #humanity.
To me, you "waste" each hour you don't spend learning something that you can teach me.
But it doesn't seem like they have some weird man-in-the-middle who needs to talk to the BDFL sometime next week, it appears more like they could simply use more people.
Or is there anything specific you're alluding to?
@hirnbrot The general complete dead air from Gargamel when it comes to responding to people who put a bunch of time and energy into contributing, and otherwise badly constricted communication with would-be contributors. There's no middleman setup like in Clojure, but far lesser barriers have turned people off from contributing to Mastodon, including me.
The only instances of something like that in Mastodon that I remember is when features like trending hashtags were introduced, where some parts of the userbase demanded them removed, (via quite rude means btw), ignoring the part of the community that did in fact want the features as irrelevant, or worse, pretending to speak on behalf of the whole community.
However, Eugen was certainly not wasting people's time or anything like that.
Any other examples?
The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!