The pickaxe guys coined it. People repeat it without thinking about it.
If matz were to say "jump from the bridge", people would do it, because matz is nice?
Just to point out: I do think matz is nice and a great language designer. That in itself doesn't mean anything. Why would I proxy my own decisions based on any mindless slogan? That makes no sense. Why do people in the ruby ecosystem keep on repeating those pointless slogans?
* DHH said some things on his blog that some people believe to be deeply racist / fascist (not going to unpack whether they were or not because answering that question is irrelevant to the fact pattern; consult other threads for that debate).
* A Ruby conference run by Ruby Central was asked to deplatform him. Since he's the creator of Rails, they declined.
* In response to their decision, a major sponsor (Sidekiq) pulled out of supporting the conference and Ruby Central in general, to the tune of $250k a year.
* This created a "blood in the water" situation where Shopify hit Ruby Central with an ultimatum: they would back-fill the lost sponsorship for oversight control of Ruby Central (and the gem repository they maintain, rubygems.org). And if Ruby Central didn't take the deal, Shopify was going to pull their funding also, leaving them in dire straits (this, BTW, is a fairly common corporate tactic when multiple partners share support of a service that doesn't independently generate revenue. Look for it in your own business, startup company, and nonprofit dealings!).
* Shopify now de-facto controls rubygems.org and people immediately started backing towards the exits because corporate takeover tends to be a harbinger of enshittification. As if to prove the point, Shopify's folks immediately ham-fisted the access controls, yanking several gem creators from the admin roles of the gems they created. They claim this was a mistake; several in the community do not want to give them a benefit of the doubt they are not believed to have earned.
* Community members are standing up gem.coop as an alternative gem repository.
I prefer the Go solution where the package manager uses the git repos instead of a separate package index that might or might not correspond to the git repos.
I think we have to wait and see how much momentum gem.coop can build. Right now they have promised "things for the future"; they will most likely also deliver eventually. But right now they are not there.
If and when they open beta, though, I'll begin to republish my old gems (not all, some I merged into other gems but most of the core stuff will be back) there. They have some things they should improve on though - documentation (also a problem that ruby doc was separate by the way), namespacing (this is in part also a problem that ruby had no primary way of namespacing; this is also a feature, but it should have a way to separate concerns when possible or wanted).
Anyway, I think we'll soon see what happens - I say people should evaluate again in about half a year or so, say like ... end of May 2026. I think this would be a more realistic time frame.
I do, however had, also suspect that DHH may become the biggest asset to gem.coop - every further snide remark he does on his blog, will gain new people who are upset, and some of those will eventually help contribute and benefit gem.coop. So for the end user this may be a win-win situation since they can install things how they like it, thus having more flexibility. Many can and will stay with rubygems.org, others may prefer gem.coop, many others will probably use and combine both (this may be a bit more difficult; guess gem.coop needs to think of a way to specify different gem sources on a per-gem basis too. Lots of work to be had for certain).
No serious business with real (business) customers will accept that kind of risk and gem.coop will never be a thing outside of hobbyists.
It tripples the attack surface making it more vulernable to having security vulnerabilities.
It took less than two weeks from this statement for them to put out an incident report from them forgetting to change the password on the infrastructure they took from the previous maintainers. I can't say I'm shocked that this didn't actually result in people's confidence in their ability as steward to provide long-term stability for the ecosystem.
IMO it would be better to start from a clean slate; dissolve Ruby Central and bring back the community with a new policy, rules - but that's not going to happen. Ruby Central went the corporate way and that's it. It would just be ironic if, say in 10 years, gem.coop proves to be much more successful whereas Ruby Central still writes the same AI-generated text ("we care for the community even if everyone is now elsewhere already").
Candidly its decentralized nature when it comes to "packages" is one of its strengths. It does have downsides, and yes GitHub could be at issue at some point.
After this, after NPM compromises (left pad and more recently the supply chain attacks) why we arent seeing more community driven changes around decentralization and venturing is beyond me.
> As a Japanese developer, I’ve been worried about the direction things were going, so it’s reassuring to see this.
I am actually much more worried now. I don't live in the USA; I don't live in Japan. To me it seems as if Japan and the USA are totally over-dominating in the ruby ecosystem. While this is understandable that it is Japan (local community, I get it, this is different to english-speaking ones), I am absolutely upset that the USA has so much proxy-influence here. But I guess there is nothing that can be done. I guess in Python the USA also over-dominates. I just think this sucks really.
Why? Japanese culture is more conservative, less prone to knee jerk decisions, and Ruby is their biggest home grown programming language.
I'm also not American nor Japanese and I think this is the best possible outcome.
I'm considering switching to Erlang, which was developed at a corporation from the start and appears to be drama and cancel free.
> While repository ownership has moved, Ruby Central will continue to share management and governance responsibilities for RubyGems and Bundler in close collaboration with the Ruby core team.
Andre has previously maintained that he owns a trademark on Bundler and he will enforce it against Ruby Central.
=> https://andre.arko.net/2025/09/25/bundler-belongs-to-the-rub...
So Ruby Central transfers "ownership" of Bundler to Ruby Core. Ruby Central gets to continue to maintain Bundler, and Ruby Core is stuck with the liability. If Andre wants to enforce his trademark, he now has to sue Japan-based Ruby Core and risk the bad optics of that.
Well,
1. He's not fighting Ruby Central anymore, he'd be fighting the Ruby core team.
2. He's going to have a tough time asserting copyright on a name he didn't come up with on a project which shipped v1 before he joined.
3. If he believes the trademark belongs to the community, the right thing to do would be to transfer it to Ruby Core then, right?
I think there are a gazillion questions left. But, I also agree that the future will tell, e. g. we'll have to see how popular gem.coop will become (if they become popular). And I also, despite my disagreements, think that it may have been better to solve installations of ruby projects from the get go, e. g. Rust + cargo. But I also see this as separate from a service such as rubygems.org (or whoever provides any infrastructure). The question of who develops functionality can be separate, I have no strong preference here. And, I also agree that having both bin/gem and bin/bundle is not good. There should be a unified API (or two - a simple one maintained by ruby core, and then people can build extra functionality into their own variants).
Sadly this all also may end up like this:
What I liked about bin/gem was its simplicity. Bundler brought a few new things or easier things to the table. "gem" should make it much easier to use any source though, including gem.coop.
I'm sorry for Ruby people that are negatively impacted, tho.
Lastly, Matz is the best!
It also seems like rubygems.org could simply fork the rubygems code, perform whatever 'security and governance' changes they believed were needed in their fork, and run with that?
Isn't that the open source way of handling disagreements in direction?
Not really. Shopify threatened to pull funding for them which set the whole thing in motion
Because I once installed your project, I need to:
- Take over all of the accounts/access you AND all of your friends/co-maintainers used in connection with it
- Tell you it was a mistake, give back access temporarily
- Do it again!
- Have one of my board members who happens to be the treasurer say it was about the $
- Make a straight to camera YouTube post Addressing The Concerns
- Make a first "continuing our series of transparency" blog post a week later, where I use a dense corporate laden dialect to claim it was for the betterment of all mankind and definitely not about the $; because I need you to understand Where We Are Now; What This Is and What This Isn't.
- Open a Google forms question submission box.
- Smear your reputation, because you had an idea once about tracking which packages go to which companies; so I'll insinuate that you want to read everyone's mail and snoop through their undergarments drawer. What's that? My actions affected much more than just you? Quiet now, we're reshaping the narrative to smear you.
- Answer no questions, explaining that we chose to give you a regular series of Friday updates; but also We Want to Move On from the back and forth but also in that same publication have another go at the smear, because it partially worked.
- Donate the project to my state library, to take some of the heat off of me
Isn't that so much easier than typing "git clone" and "git remote add"?
(I am consistently flummoxed that a handful of people here are buying this narrative; instead of as you point out... Just applying a smidgeon of critical analysis about the usage of tools that the majority of us must use day to day and coming to the conclusion you do. Instead of doing this or accepting this conclusion, there's a frothy passion it seems for Appeal to Authority/Argument from Authority where any excuse, flaw, etc on the part of the maintainers is used to justify the whole chain of events.
It seems like it hits 5-7 facts and people can no longer manage them in short term memory, go and look at more than what is presented to them by a single party, etc; so they just default to the easiest mental shortcut.
For some reason I keep falling into the trap that "people are more educated, capable of critical thinking, and have easier access to data than ever before in history"; which I rationally know is not true)
I don't believe this has anything to do with DHH.
It's good to hear Ruby core team took the ownership. Thank you Matz.
Why is there (seemingly) no public offer to former maintainers to rejoin, or acknowledgement of wrongdoing having been done as part of this? It's practically zero cost to do that; as the Ruby core team is (largely) not the party that inflicted harm.
Politeness? Conspiracy to have done this all along? Cultural differences around public vs private opinions? Something else?
What would we think if this wasn't a software project but a hijacked community bus, being passed from party to party, pretending nothing is untoward about the whole situation while the passengers are still aboard? "Oh good, the new bus drivers are politely accepting the keys from the hijackers; all is well!"?
Edit: https://www.reddit.com/r/ruby/comments/1o8zz3e/comment/njywb... No discussion with maintainers
In my 17ish-year involvement with Ruby, I can't think of one.
For instance, who effectively controls the ruby ecosystem? See ad-hoc restrictions such as 100.000 downloads - past that point you are disowned from your own gem. I always felt that was a direct attack on independent developers. They could have forked those gems just fine (the licence permits this for most gems after all), but nope, they forbid you to remove your own (!!!) code.
By using signed packages. Why is this even a question.
I'm not counting something like C++ where there's effectively no "packages" to speak of.
However I would say all ecosystems have issues, regardless of the approach, because 99% of the developers have no clue on what they depend on, and there are plenty of ways to mess up with ecosystem.
Btw, I’m definitely not saying anything is doing this really well yet, but I do think Linux distributions are a pretty good implementation of it. I think it would be pretty difficult to stamp out Linux and Linux packages.
Deno does also but I'm less clear on well how that is working out for them.
See especially Mike McQuaid's summaries. He did a bunch of mediation and comms work to make the situation digestible to outsiders. Check his recent posts (at time of writing) on https://bsky.app/profile/mikemcquaid.com
Tensions within the community were heightened because its loudest voice and most recognizable figurehead has opinions that aren’t all that popular and he made them loud and clear as he’s a loud thinker.
I've been working on Homebrew for 16 years and leading it for some proportion of that and this all "smells" like a more sustainable long-term solution than anything we've seen happen in the last year. Some proposals sounded nicer but were not going to be acceptable to one or more sides.
Ruby already provides a vendored version of RubyGems and (more recently) Bundler so this seems appropriate. It also separates the "running a web service" which has guaranteed hosting costs, requires on-call, etc. from "running an open source CLI/library" which has no guaranteed costs.
It will be interesting to see what the Gem.coop folks do now (disclaimer: I helped them with their governance process). If there's some competition for rubygems.org as a server implementation that feels like a good thing for the community overall.
Good luck to all involved on all sides.
Rails is still a good web framework within its limits. If you want to build a small, modest complexity web app with like 1 or 2 developers and under maybe 6 months of active development, modest traffic needs, etc, it's a good way to get everything up and running fast with best-practices for everything.
The lack of types may start to pinch some once you get an order of magnitude more developer-months into the app than that. Lack of overall speed, threading issues, and memory usage may be an issue once you get a few orders of magnitude more traffic. But while you're within those limits, I think you'll get features out on it faster than any other language or framework.
As they say, a lot more startups have died due to not being able to iterate fast enough in the early stages than from their traffic capacity, hosting efficiency, and bug count once they get into serious growth.
Of course lets silently ignore Github, Gitlab, Shopify and others: all small, modest complexity web apps built with Ruby on Rails. Look at Shopify last year black friday numbers and come back and tell us how Ruby is fit only for modest traffic.
Big legacy companies who have invested heavily into Ruby cannot switch but every shop I’ve been at often started new services in non-Ruby (mostly Go but have seen plenty of Node/TS as well or Rust for that matter).
If I were to start a new app Ruby would be far from my first choice and the biggest reason are types. After being in the weeds of big Rails apps while also working with Go/Ts/typed Python, Ruby seems very fragile in big codebases. Sorbet is also not enough.
I'm unaware of one ever happening, and I'm wondering whether it's because of mere fortune or because there's something about the APT / dpkg model that precludes this kind of messiness.
Perhaps the Ruby community is suffering the curse of having lived with reliable Internet for so long they never had to solve the problem of building up automatic package mirrors? This just feels like a lot of words and energy burned on a problem that ought to be as simple as "Here's the package, here's its checksum, go to town."
That said, there's been quite a bit of drama lately in prominent Linux projects — notably bcachefs, X11 (and the fork XLibre), and the Omarchy distribution (even connected to the current story!).
It is not 1:1 comparable though. Ruby, python etc... have a much more varied community. People contribute code. Only few contribute to the linux kernel directly. There are many more who write "apps", so this could be comparable. Still it feels different to me, since a language community is different to a community that uses different programming languages.
> Perhaps the Ruby community is suffering the curse of having lived with reliable Internet for so long they never had to solve the problem of building up automatic package mirrors?
No, I think it is more that people never anticipated that corporations could take over projects. This has become more of a problem in the last years. Who controls github, for instance?
> This just feels like a lot of words and energy burned on a problem that ought to be as simple as "Here's the package, here's its checksum, go to town."
This is the issue of decentralized hosting versus top-down control. Ruby didn't have that problem in the past. It became more of an issue in the last some years. See DHH having an old tweet where he pointed out that he wants more control; I think this was from 2018. I don't remember it fully but it is on the ruby reddit.
I've even seen unironic claims of certain pieces of technology containing "Hitler particles". That shook me a bit because that's an old in-joke and was always intended to be a joke...
I find “BDFLs” and open source communities so incredibly interesting. Especially in the context of geopolitics and state entities. Linux!
This stuff is PHD material for sociology and polisci post-grads and I’m so interested in following the progression of history with these types of things.
https://blog.pypi.org/posts/2023-05-25-securing-pypi-with-2f...
See that question asked:
"Isn't supply chain security a corporate concern?"
He tries to bring arguments to invalidate that. And failed in an epic manner. Now people are more suspicious than before. Kind of strange to see, too.
Not up until the incident that motivated him to resign, anyway.
I feel like BDFLs are akin to the concept of village elders; they're not immune to corruption or scandal, but they often have this beloved status that can paper over a lot of cracks. That's probably dependant on their leadership style - the hard headed (Linus, DHH) vs the grandfatherly (Matz, Van Rossum).
Which, going back to your note on geopolitics, leads me to wonder: Is it just that more power corrupts more, or is it that (modern-day definitions of) democracy require a desire for power? I guess as the "FL" part of "BDFL" comes to bite more of the communities, we'll see better how different succession styles have different effects. I also wonder if the analytical nature of the individuals within the "populations", and inability to police defectors will mean uprisings will be more successful, either in causing BDFL attitude adjustments, or just overturning the community completely (for example, there's already a lot of momentum for a complete fork of Rails)
(Edit: having submitted this, I now see others have had very similar thoughts! Definitely an excellent conversation topic)
I think a lot of this is due to how so much is a scandal these days, for better and worse. (I'm obviously going to keep politics as much out of my response as possible.)
A few decades ago, people could have political views without ostracizing roughly 50% of the global population, or generally causing a ruckus at the holiday family dinner. (Obviously politics + holiday dinners has been an issue for a long time, but back then it was just something people tried to sweep under the rug. Now? Holiday dinners are getting cancelled or families are splitting up.)
It used to be that a scandal in the OSS community required you killing your wife (thinking back to ReiserFS). Now, a remark on Twitter is all it takes.
Again, I am absolutely not taking sides here. I'm just noticing a difference in the times, and agreeing that it is indeed interesting to watch.
The diference is that with an open source licence, the comunity can just fork the project (assuming they have enough developers), so the BDFL must master the art of herding cats.
A country has clear phisical borders and tanks, and people can't fork them and ignore the old power structure.
I think there's going to be an interesting and complicated churn as several major projects under the BDFL model have their Ds succeed at passing the torch, struggle to pass the torch, struggle to realize the torch needs to be passed, or take the torch and do their best to burn the whole project down so it can't outlive them.
At the same time, I would like more information around how the Gem supply chain will be handled, particularly how Rubygems and Bundler will be protected against supply chain attacks, which are becoming endemic.
Is Ruby ecosystem doing well?
Hoping for some context
> Shopify demanded that Ruby Central take full control of the RubyGems
For the DHH thing he wrote a recent blog post where he said he wants fewer non-white people in London and praises an english far-right fascist figure (Tommy Robinson)[1].
Not really sure about the Shopify stuff. I've heard people aren't too fond of Tobi (the C.E.O. I think), and he's buddies with DHH, but it could just be general distrust of a big company trying to exert control of an open source project (through Ruby Central).
No, it turns out DHH really wrote a blog post complaining not enough people in London are white (even though they’re British) and praising a famous British fascist.
The rest is very much still confusing, some kind of opportunistic power plays and typical open source chaos.
Edit: Seems like maybe a hostile take-back actually.
gem.coop matures and people move to it
Or ruby central gets their crap together and regains some trust.
It's definitely a win that the tool entry point is now managed by competent people with a good track record that aren't involved in the current drama.
- Politics at work were becoming a huge problem at 37Signals
- They asked that politics be kept out of company chats, but encouraged people to be political active on non-work channels/social media/etc even during work hours
- People lost their minds at this incredibly reasonable request which then blew up on the internet
- They offered any employee 6 months severance if they weren't comfortable with the new policy. About 1/3 of the company took it.
- Rails Conf dis-invited the creator of Rails
- Obviously, this was not going to sit well as people were trying to create a very public political flex against DHH and at that point, he started getting much more vocal about the problem of politics sweeping into every aspect of life.
In the following years...
- DHH becomes very publicly outspoken against politics infecting everything
- 37 Signals publishes another successful book
- Ships much more quickly as all of the people constantly distracted by politics at work are no longer in the building
- Starts the Rails World conference to great success
- Rails Conf shuts down
- DHH ships Omarchy which is getting significant support
So the end result has been that a bunch of people tried to essentially "cancel" DHH and the result was him having virtually non-stop, resounding success while publicly speaking out against those who created the problem in the first place...because some people really do just want to build cool things regardless of your politics.
Then he started a blog, built on his companies software, where he constantly shares extreme political opinions. When you are the public face of a company (and framework) and you are publishing your political opinions using your companies platform, you are now bringing politics to work. He’s a hypocrite.
I think the real root of peoples' disagreement over what happened there is that rank-and-file employees wanted to assert a lot more control over what their company does than they actually could and they were informed that that wouldn't be acceptable. The six month severance was generous.
but you've omitted his recent "contributions", where he went completely off the rails
have a read of this https://world.hey.com/dhh/as-i-remember-london-e7d38e64
it's completely unacceptable, and he's promoting a self proclaimed fascist white nationalist (Tommy Robinson)
Keeping politics out of work place is like an extremely mild stance.
For some reason, people label him as facist...
As far as I can tell, this doesn't fairly reflect what actually happened. Ruby users were free to keep their own political views to their own blogs, just as DHH does. Reading world dot hey dot com slash dhh is not in any way required in order to use Ruby, participate in the development of Ruby or anything else along those lines.
There are a lot of prominent developers in the Python community whose politics I strongly disagree with. I got banned from the main discussion forum as a result of objecting to hidden Code of Conduct enforcement principles which (in my view) attempted to bring (many of) those politics in through the back door. (And in the process of getting into that meta argument, and doing research, I encountered several previous unpleasant incidents on the forum and on the mailing list that preceded it.)
But I would never start arguments with people in that space over things they wrote on their blogs. I would not go onto, say, the CPython issue tracker to complain about how certain people needed to be removed from the project because of things they said in their own spaces (like we saw with, for example, Opalgate). If I wanted to talk about someone else's politics — or my own — I would and could use my own blog for that.
The mere fact of people knowing DHH's politics emphatically does not politicize Ruby, Rails or any related project. To the extent that Python development has become politicized, that's a consequence of actual enacted policy, not the political beliefs of steering committee members, PSF board members etc. DHH putting this content on his blog was part of the effort to have it not in the workplace. And, in point of fact, that does keep it out of 37Signals board rooms.
For instance, I pointed out days ago that Hiroshi Shibata did not act solo. Now this is confirmed - it was a matz directive. The main question to ask here is: could he not have made this open AND public from the get go? It would have lessened the confusion for some people.
Unfortunately this also has a few added problems now, because ... say that you are an indie dev or a solo dev. Would you want to "interact" with the ruby core team if they can just oust people at will if they feel they need more top-down control? Or, worse, if they only get money if companies pay them to do so? I am not necessarily saying there was a 1:1 connection with money in mind. For instance, the bin/gem was not designed by the ruby core team, in many ways was a mistake from the get go - see how Rust avoided this by having cargo. But one can not help but wonder how deep that money situation goes. u/jrochkind on reddit pointed that out, e. g. that there is very clearly a connection to ruby losing users and developers in the last ~5 years, and a dry-up of financial assets in general. I agree with him. Even if this was not the case here (though I somewhat suspect money had to do with many things here), the situation for ruby in general is really really bad. Perhaps matz felt that this was the only way forward, who knows. Either way it is not a good situation to be had.
It also shows how ruby is WAY too dependent on rails. If rails sinks, ruby sinks. That is BAD. DHH may contribute to this problem with the "I am the richest neo-boy in the USA" and odd blog entries (that's his though, he can write whatever he wants to), but the moment there is a financial interconnection is the moment there is no longer a fair field. And this is really bad, because it means ruby as such will be pulled by those who have money. Bye bye solo devs - you no longer have a place in the corporate infrastructure. And make no mistake about this: rubygems.org is a pure corporate entity now. Look at the new rules they forced onto everyone: https://blog.rubygems.org/2025/07/08/policies-live.html
This also reminds me of Pypi, by the way:
https://blog.pypi.org/posts/2023-05-25-securing-pypi-with-2f...
Quote:
"Isn't supply chain security a corporate concern?"
And then he weakly tries to say "no, it isn't because corporations finance us now, it is all about LOVE, HAPPINESS and THE COMMUNITY". But in reality - it absolutely is. Corporations wanted more guarantees and these inrastructure-maintainers said "that's ok - we don't pay these indie devs anything but now we force them into mandatory 2FA, ad-hoc 100.000 restrictions (can not remove your gem past that limit) and any other random crap, such as not paying them anything and having them work for us for free". I am sorry but there are soooooooo many things going wrong here - I totally agree with duckinator. This was a hostile take-over, unfortunately now we also know that it was decided from within ruby-core itself.
Note that I am not saying that it is a bad idea to have something such as gem maintained by the ruby core team, I totally understand the reason for this, and I also pointed at the example of rust/cargo. However had, the infrastructure shouldn't be a money-injection team for the ruby core team - the moment this happens is the moment things no longer work here. And ruby isn't merely the part designed by the core team; it also isn't just rails - you had many more people who contributed to ruby in the form of the ecosystem. Granted, many projects are abandoned (this is also a problem for rubygems.org by the way) but at the least this used to be true in the past.
In a way this is all a bit rubbish, because we see MIT/BSD licences, so people could just fork ruby (not that this is likely; I haven't seen anyone object to matz being an excellent language designer. I also don't think it is a problem if matz and the core team profit from this financially, that's perfectly fine. But the whole ecosystem shouldn't be in such a top-down control where corporations just buy their way into things, with DHH making snide remarks on his blog ("we got rid of the boys controlling the infrastructure now") all of the time while on Shopify's payroll - that is no longer a fair playing field here. Everyone can see this.)
Also, if matz made the decision weeks ago and told Hiroshi to do so, HOW was this fair to Mike McQuaid? The latter said he tried to act as man in the middle. But if the decision was made to finalize on this already prior to that, was Mike told that? If not, how is that fair? Either way I guess Mike gets the most praise from all sides simply for trying.
We'll see what happens, whether people love the new corporate-controlled rubygems.org or prefer gem.coop (which, admittedly, still have to deliver). I favour the latter, like the rising phoenix from the ashes - in part because I hated the new corporate rules that was installed onto rubygems.org, including the crap 100.000 download limit, but in part also because I feel that if gem.coop gets enough momentum overall, they can actually begin to solve NUMEROUS issues in the ruby ecosystem, from documentation to namespaced accounts (users and the ruby code as such, see duckinator's proposal) and so forth. Considering the damage shopify caused while wanting to control more of the ruby ecosystem, I expect them to now send more workers to go and improve rubygems.org as much as possible - and not ruin things in the process. Otherwise they would have only caused damage without any real gains.
The biggest loser in this are actually the folks at RubyCentral. Because ... what have they really ever done for the ruby community? Which high profile gems have they maintained? Just throwing fancy parties isn't going to cut it - Titanic was also sinking when it hit an iceberg. RubyCentral may still celebrate while sinking ...
> Now this is confirmed - it was a matz directive.
I did not see any confirmation in this annoucement, do I miss something?
Speaking of Phoenixes this whole debacle made me start diving into Elixir/Phoenix. My first impression is that I much prefer Ruby as a language, however I'm struggling to even think of using Rails currently.
They were stolen from André Arko, Colby Swandale, David Rodríguez, Ellen, Josef Šimánek, Martin Emde and Samuel Giddins.
When you left RubyGems and Bundler (let's call them "Projects") team, you handed over your authority to whoever was left and/or was added later. It doesn't matter in which order things happened. What matters is that Ruby Central _and the rest of the team_ were the stewards of Projects. The important part here being _and the rest of the team_. André had every right to keep being part of that team, and he was for a long time, together with many other team members, all of which were removed by "a representative from Ruby Central". What an inhuman way to remove someone from a Project. "Hire" someone to do the dirty job for you so you don't have to. The decisions in a team should be done by reaching a team consensus. Not by one actor. I believe it's for the better that André was removed from the team, but it shouldn't have been done like this. Ruby Central lost their trust in the eyes of many. They could've achieved the same goal in a much better way. How can I trust an organization with management of something if they failed to manage this whole situation? Claiming this is all in the name of security and then not even knowing how to properly remove access from someone. So much about security...
It may be best in the future direction to have Ruby Central's role on RubyGems and bundler completely eliminated and simply just hand them over to Ruby Core and Ruby Foundation in Japan. I will gladly donate just to avoid any more US politics and drama.
What was your maintainership status when this all kicked off? Were you one of the owners removed by HSBT?
Joel Drapper is fibbing & playing memory games in a weird attempt to exert ownership over the community. It’s good to hear someone credible set the record straight.
As long as Matz is involved, I have a lot of faith things will get better, not worse, unless you have some strong indication of otherwise. If anything, because things will be nicer.
NPM was a company and it was acquired and it was voluntary. I don't think you can compare it to this situation - this is more of a messy situation with everything open source collaborations, rather than having clear ownership in a single entity:
https://github.blog/news-insights/company-news/npm-is-joinin...
Or are you referring to the pre-2014 situation where NPM wasn't VC Funded, but in a more nebulous state? It didn't last that long.
