This is a disappointing look for Ruby Central. I have to get back to work, but their retroactive framing that Andre and Samuel's work on RV justified Ruby Central's subsequent actions is contradicted by their own admissions.
By their own admission, André is a contractor to Ruby Central. Contractors, especially under California law, have no contractual obligation of confidentiality to the other party unless there's a pre-existing agreement in place. They later admit in this "incident report" that they didn't have any legal agreements with André in place, so there's no basis for claiming André couldn't work on rv.
Samuel was an employee, not a contractor, but [California Bus. & Prof. Code § 16600](https://leginfo.legislature.ca.gov/faces/codes_displaySectio....) voids non-compete agreements—so even as an employee, he had every right to work on a competing project. There's no indication that he used Ruby Central's proprietary information to do so, and the report doesn't allege that. I have little doubt that if Samuel or André used proprietary information to develop rv, they would have already presented evidence of that.
Independent of the legalese, a "uv but for ruby" is a blindingly obvious thing to do, and Ruby Central doesn't get to lick the cookie and get upset when an independent contractor—Ruby Central's own characterization—does a thing they didn't fund.
My sourcing on this is that I run a 10-person business with employees in California. I'm not a lawyer, but I looked over enough of this paperwork that I feel confident opining on an internet forum.
That wasn't my read of what the postmortem is claiming. I didn't see a claim that anyone did anything illegal with proprietary information and the only legal question anyone raised was around a tangentially related proposal with user data[1]. I think the question about working on competing work is unfortunately more grey than most on HN would like, but even then nobody was fired/terminated for that. It sounds like people voluntarily left.
My biggest takeaway from this is the intermingling of opensource work/foundations/companies and employees/contractors/volunteers needs to be incredibly explicit. It sounds like everyone had very different expectations about what this group of people was (ranging from an exclusive club of influential ruby developers to a very formal, business-like foundation) and, as a result, each other's actions seemed hostile/strange/confusing.
[1] I actually think the comments about the proposal of selling the user data does a disservice to the postmortem. I think it invokes a much more emotional reaction from the reader than anything else and, while potentially interesting, seems like dirty laundry that doesn't change the lesson the postmortem teaches.
The document didn't mention a lawsuit and I was just responding to the above comment with only the context of the postmortem and pointing out that this particular article didn't claim anything illegal happened. You and some others here might have much more context that I or other readers of this postmortem don't have.
I seem to remember there were some threats of legal action related to unauthorized access after this kerfuffle but I a) don't know what is going on with that, b) don't know what the law actually says about that and c) don't know if that is what you are referring to. If so, I think it is different than what the original comment alleged which was more about moonlighting/using proprietary information/competing. I think that topic is extremely complicated (e.g. I am not so sure moonlighting for a competitor while an employee is necessarily protected in California...) but that wasn't alleged in the postmortem anyway.
> The document didn't mention a lawsuit and I was just responding to the above comment with only the context of the postmortem and pointing out that this particular article didn't claim anything illegal happened.
You are correct that they did not make any claims, but the article did insinuate illegal behavior on the part of André and Samuel by selectively juxtaposing facts to imply wrongdoing without ever directly stating or saying that their behavior was illegal. For example:
1. André's first commit on RV is placed on the same bullet point as the Ruby Central-funded maintainer offsite, which implies Ruby Central's travel money subsidized a competing project's creation.
2. The `rubygems-github-backup` access token covering "all repos, including private repos" is introduced in the same timeline section as RV development, without any allegation it was used for RV.
3. The "Incident Lessons" section recommends adding an "Outside Business Activities" declaration policy, which only reads as a "lesson" if André's undisclosed side project is being framed as the problem in need of remediation.
4. The report states André "had intimate knowledge of the foundation roadmap" and "did not tell anyone in Ruby Central about this work until it launched". This frames nondisclosure of a lawful side project as a transgression. However, Ruby Central passed on this work, and even if they didn't, André has no obligation to tell Ruby Central about his work!
5. André's proposal to have his consultancy analyze RubyGems.org download logs is presented alongside an OSS Committee member raising PII and "reputational risk" concerns, casting a perfectly sensible rejected business proposal as something suspect.
By my count, Ruby Central makes roughly 10 insinuations throughout the report, but not once do they actually claim any of these constitute a transgression.
> I think that topic is extremely complicated (e.g. I am not so sure moonlighting for a competitor while an employee is necessarily protected in California...)
California is actually quite clear on this! Bus. & Prof. Code § 16600 voids non-compete agreements, and California courts have consistently read it broadly enough that working on a competing project during employment is protected. The line is whether you used your employer's proprietary information or resources to do it, not whether you competed. The report does not allege that Samuel or André used Ruby Central's proprietary information, and given how thoroughly they documented everything else, I'd expect them to have said so if they had evidence of it. Ruby Central is insinuating that working on RV in the first place is a problem, not that they crossed any legal or contractual line.
I might be reading it wrong, but it sounds like you and some others here are either more closely connected to the folks involved or at least have more context. I don't want to imply that I know better what the author or anyone at Ruby Central _actually_ believes or is doing, I'm just commenting on the article at face value. Whether the article is true, deceptive, or in between, I think there is still an interesting general lesson about organizations in it.
> You are correct that they did not make any claims, but the article did insinuate illegal behavior on the part of André and Samuel by selectively juxtaposing facts to imply wrongdoing without ever directly stating or saying that their behavior was illegal.
I think we just took away something very different from the article. I didn't read it that way, I read it more as "these two have already decided to move on to work on this without Ruby Central so it's pragmatic to cut off their access". We might just need to agree to disagree on what the article implies; perhaps we are just reading it with different boundary conditions.
Where we might agree is that repeatedly bringing up the selling user data proposal doesn't add anything to the story except to prejudice the reader against Andre. If it's to show that there was still some communication between Andre and others at Ruby Central, I would have kept it at that. Every time it got mentioned I winced.
> California is actually quite clear on this!
My understanding is quite different. There is a duty of loyalty an employee owes their employer and directly competing with your employer is clearly a breach. There is recent enough case law on this (at least covering terminating an employee for cause as a result). I don't have access to the materials from a previous employer that explained some of this but I did quickly find [1] which roughly agrees with my recollection (though I would not be willing to vouch for this particular site), namely "that Section 16600 has consistently been interpreted as invalidating any employment agreement that unreasonably interferes with an employee’s ability to compete with an employer _after_ his or her employment ends".
I'm not a lawyer (I assume you aren't either but at the very least you aren't _my_ lawyer) so I think it's not worth debating this further, we seem pretty firm in our beliefs on this one.
EDIT: I want to acknowledge that one of the individuals here was a contractor and not an employee. I have no idea how that factors into moonlighting restrictions. I imagine it would be more limited and lean more on what that individual's exact role is at the company? I think my point still stands that my understanding is that the general situation for the average software engineer is more nuanced.
There is a lot of tension that the report seeks to either minimize or avoid. It’s also just really hard to express it in a report like this because there’s no real place for it if the goal is to look professional.
I think the RubyGems fiasco was a result of unresolved tensions. People chose not to be adults about and resolve the issues respectfully. IMHO, I think one of the main problems is that nobody was willing to spin up a core foundation to own critical infrastructure to the Ruby community which remains a problem.
I cannot find the blogposts I remember reading, but recall that there were some bad feelings about Ruby Together and Arko’s leadership of it before it was merged with Ruby Central. It appears these feelings never went away which is made very clear by the way that key Shopify engineers started posting after Ruby Central took over the RubyGems GitHub org [1].
Now combine this with dhh’s right-wing political posts and behavior, his extremely close relationship with the founder of Shopify (dhh is on the board of Shopify), a key Ruby Central donor pulling critical funding because he did not want his money going towards giving dhh more attention and you’re left with Ruby Central effectively being controlled by Shopify (which, as far as I can tell is still the situation) because that’s where all of its funding comes from now.
Frankly, the biggest thing this entire fiasco has shown me is that a lot of us are still a bunch of idiotic teenagers. Integrity and maturity is in short supply where it is needed the most.
> I cannot find the blogposts I remember reading, but recall that there were some bad feelings about Ruby Together and Arko’s leadership of it before it was merged with Ruby Central.
uv is Astral's onramp to paying customers. Without uv's tight integration with Astral's other tooling that they want to charge for, they wouldn't be able to sell anything. Building a business around doing the same for Ruby may be within their rights, but it's absolutely a conflict of interest working or contracted by Ruby Central. Removing them was an obvious move.
If this is a conflict of interest, then any Ruby core systems being controlled predominantly by members of the Shopify dev team is itself a conflict of interest. I am fine saying 'we need to make sure these libraries stay independent and community controlled', but that is so clearly not what was going on here. Believing that is just letting the RC FUD and PR control your thinking on the narrative.
I'm sorry but what are Shopify's business activities that directly compete with services provided/maintained by RubyCentral?
As far as arguments about community, Shopify IS the community by virtue of being the ones putting up pretty much all the money to keep this ship afloat.
If you don't have skin in the game your positions won't be taken seriously.
Depending on your point of view, Sidekiq either turned their back on the community or tried to start a coup by pulling funding just so they could morally grandstand.
That attitude is exactly the problem. Shopify does not 'keep the ship afloat' they are just a corporation using open source systems as the foundation of their business. Competition is not by definition the backing of a 'conflict of interest', it legally refers to a person or entity with a stake in a particular outcome having control of the means to achieve that which are not legally sound , ie compromise their judgment. I think Shopify's judgement of what 'is good for the Ruby community' is severely compromised by their corporate interests, and probably by their boards political interests as well. Hence, why they are trying so hard to justify removing Andre.
Do you have any idea how expensive it is to keep the infrastructure running? RubyCentral's operating expenses are in the millions every year and exceed their revenue.
Andre's removal is easily justifiable by his own (lengthy history of) sketchy behavior.
Since when is "open source" something businesses shouldn't be allowed to get value from or even have a stake in? These things are MIT licensed. That's free as in speech AND beer. If you don't like the freedoms of the license and how other people use them, don't use the license. If you don't like someone's stewardship, fork and maintain your own.
> Do you have any idea how expensive it is to keep the infrastructure running?
Yes, I do. All hardware and bandwidth are donated by Fastly and AWS so it costs RC nothing. Their expenses were $20,000/mo for 24/7 ops coverage: $2000/mo for 6 people and $8000/mo for service maintenance (e.g. db and software upgrades). So $240,000/yr, not "millions".
Care to cite the dollar amount of Shopify's yearly contribution (not even counting the humans doing actual labor) and what Sidekiq pulled in funding while you're at it?
I don't know the details of Shopify funding. I donated $250,000 in 2024 and withdrew a planned $250,000 donation in 2025, as has been widely publicized.
Responding to your first paragraph, the rest wasn’t constructive.
Shopify paying for infrastructure related to Ruby is an investment, not charity. Hosting gems costs money and a healthy community depends on that gem hosting. Spotify, in turn, depends on that healthy community to produce and maintain gems, train future employees, stuff like that. They’re not paying that money for fun, it is to protect their interests.
And all of the above would be true even if the OSS committee wasn’t 100% Shopify affiliated. That’s gravy.
Those who write the code have more of a right than those who pay the bills. Anyone can write a check. A select few have the acumen and experience to actually write the code.
You can't unilaterally declare someone "sketchy" and then kick them out in the name of conveience.
No I'm calling him sketchy because that's the sentiment anyone who has been around in the community long enough and dealt with Andre has about him. This is very openly discussed and documented and not just in the aftermath of this event.
People having concerns about Andre's behavior around his money and his open source contributions can't even be called an open secret.
The narrative that one side of this is pushing that this is some little guys vs evil corporate overlords problem is short-circuiting so many peoples' ability to rationalize about this topic.
This is about the personal failings to communicate and organize among a very small group of highly skilled, highly productive people. It's also about how they have fallen into camps and try to apply institutional and social leverage in order to influence millions of bystanders in order to maintain/wrest control. Each credibly accusing the other of doing it for their own benefit.
Nobody is in the right here. If you can't engage with that as your starting point, you aren't serious about this conversation and are just spouting one side's propaganda.
In the aftermath us bystanders are left wanting either stability or revolution. Revolutions generally aren't good for anyone. Especially the people who want it the most.
Honestly fair. There's a little too much of my personal distaste with his actions coming through here.
I think it's fairer to say that if you know him and you are in the community than you know that these opinions of him are had. That is not normal.
I also want to make it clear that there is a separation here. I do not think that Andre is a malicious or bad person. I just have questions about his decision-making based on things he's said & actions that he's taken and that leads me to think that he is untrustworthy. Not in the "will steal from me" sense but in the "will fuck up shit that I care about" sense (which ultimately he did, at least partly, whether through direct actions or poorly maintained relationships with key people). I work with this kind of infrastructure though and that's the kind of attitude that you want to have towards people to be able to do this job effectively. I don't trust a lot of people -- I want any access they have to be out in the open, limited to what's needed, etc. Governance of the project/organization was obviously a shit-show.
When I say that it's obvious to cut ties with him, I'm looking at it from the perspective of someone responsible for a high-profile project. I would make that decision 10 times out of 10 without regret. They still absolutely bungled the crap out of how that went down.
Also, I hate that this crap gets associated with the "Ruby Community". It's really just a subset of the western Ruby ecosystem that cares about foundations and events and semi-social functions. Ruby's core and a whole ecosystem of people working on and around Ruby couldn't give a crap about any of this and it's all just a massive inconvenience. Meanwhile on boards like this everyone is planting their flags and trying to exploit chaos to create change in critical services that people absolutely depend on.
> is short-circuiting so many peoples' ability to rationalize about this topic.
It appears unfair. That's the extent of my rationale. I've not seen any concrete evidence to draw any further conclusion than this. If you're managing a project and you're not cognizant of this, you probably shouldn't be managing projects; in particular, you should stay away from open source projects with a large base of volunteer contributors.
> Nobody is in the right here.
So, they went through all of this, made themselves look bad, cast tons of aspersions, and in the end, they weren't even in the right? This seems a shabby defense.
> are just spouting one side's propaganda.
I don't care about one side or the other. You see this giant crater left by these decisions though? Yea.. that's the problem.
> that's the sentiment anyone who has been around in the community long enough and dealt with Andre has about him.
I've known him personally for years and find him perfectly fine as a person. The Rubygems maintainers worked with him for the past decade without issue. Until you cite actual issues, not vague "concerns", you're just spreading FUD and innuendo.
I don't need to rehash 10+ years of documentation that's all over blog posts and prior threads on this very topic. Even if someone is unfamiliar with the details they can casually google RubyTogether and Andre and find out all kinds of details.
Don't pretend like I'm some nutter flinging wild accusations when primary and secondary actors in this story literally voiced these concerns in emails during this event.
Anyone who has been following this saga and actually cares knows because they read it already.
I have read many of the allegations against Andre, and find them to fall into:
1) Hyperbolic takes on a perceived 'communication problem' when Andre defends strong design decisions that have impacts on the Ruby ecosystem. Anyone doing what Andre does is going to have impacts on the ecosystem, that is the point. I think the ease of maintaining Ruby systems speaks to the overall good outcomes these discussions have had, and Andre's part in them.
2) Personal dislike of Andre due to disagreements over politics and/or worldviews, usually stemming from assertions of 'woke code' or something like that.
3) Distaste over Andre trying to make a living off doing what they love. This is usually couched in the 'shady' type language you have used a few times. I think that is a weird take on what are just common schemes to use data for monetization purposes, so that Andre can make a living doing design and maintenance. Nothing I have ever seen makes me worried for my data in Bundler or Rubygems.
If your main concern is that 'bad things could happen with Andre running Bundler' I have to question if it isn't just as likely, if not more likely, that bad things will happen with a Shopify run RC board running Bundler. Their motivations are much less clear other than being a corporation that is profit driven, so I can't say with confidence they won't put that motive above 'good software decisions' when push comes to shove. I don't see them as de-facto making the Ruby supply chain better by any means. Time will tell.
(Hi, I’m on the rust-analyzer team, but I’ve been less active for reasons that are clear in my bio.)
> Language servers are powerful because they can hook into the language’s runtime and compiler toolchain to get semantically correct answers to user queries. For example, suppose you have two versions of a pop function, one imported from a stack library, and another from a heap library. If you use a tool like the dumb-jump package in Emacs and you use it to jump to the definition for a call to pop, it might get confused as to where to go because it’s not sure what module is in scope at the point. A language server, on the other hand, should have access to this information and would not get confused.
You are correct that a language server will generally provide correct navigation/autocomplete,
but a language server doesn’t necessarily need to hook into an existing compiler: a language server might be a latency-sensitive re-implementation of an existing compiler toolchain (rust-analyzer is the one I’m most familiar with, but the recent crop of new language servers tend to take this direction if the language’s compiler isn’t query-oriented).
> It is possible to use the language server for syntax highlighting. I am not aware of any particularly strong reasons why one would want to (or not want to) do this.
Since I spend a lot of time writing Rust, I’ll use Rust as an example: you can highlight a binding if it’s mutable or style an enum/struct differently. It’s one of those small things that makes a big impact once you get used to it: editors without semantic syntax highlighting (as it is called in the LSP specification) feel like they’re naked to me.
For another example of semantics-aware highlighting for Rust, see Flowistry, which allows you to select an expression in order to highlight all the code that either influences or is influenced by that expression: https://github.com/willcrichton/flowistry
Flowistry publishes their underlying rustc plugin as a crate, so all the analysis is already done for you, you'd just need to integrate the output with your editor of choice.
Thanks for sharing this project! That's a really neat idea and would help me a lot with understanding code written by others. It's unfortunate that it's only available for Rust, but it makes sense that the language design really lends itself to this.
Looking at this, I noticed how long it's been since I saw a new IDE feature that really made me more productive at understanding code. The last I can really remember was parameter inlay hints. It's a bummer - both the Jetbrains IDEs and VS Code seem to only focus on AI features I don't want, to the detriment of everything else.
Another pretty common application is to color unused bindings with a slightly faded-out color. So for e.g. with the TypeScript LSP, up at the top of the file you can instantly tell what imports are redundant because they're colored differently.
I think it's funny that some languages, like TypeScript, use a different programming language to improve their compile times.
Then there are languages like Rust who are like, whelp, we already use the fastest language, but compilation is still slow, so they have to resort to solutions like the rust-analyzer.
> they have to resort to solutions like the rust-analyzer.
It's not really a bad thing. IDEs want results ASAP, so a solution should focus on latency; query based compilers can compile just enough of the source to get the answer to a specific query, so they're a good answer.
Compiling a binary means compiling everything though, so "compiling just the smallest amount of source for a query" isn't specifically a goal, instead you want to optimise for throughput; stuff like batching is a win there.
These aren't language specific improvements, they're recognition that the two tasks are related, but have different goals.
We (the rust-analyzer team) have been aware of the slowness in Rowan for a while, but other things always took priority. Beyond allocation, Rowan is structured internally as a doubly-linked list to support mutating trees, but:
1. Mutation isn’t really worth it; the API isn’t user-friendly.
2. In most cases, it’s straight up faster to create a new parse tree and replace the existing one. Cache effects of a linked list vs. an arena!
In fairness, I don’t think we predicted just how large L1/L2 caches would get over the coming years.
One of the rust-analyzer co-maintainers (Chayim Friedman) already rewrote it, but we can’t integrate it yet, as about 40 assists (the little lightbulbs?) still rely on mutation. If you want something Rowan-like, I think syntree and Biome’s rowan fork are good options to look into.
How about cstree? https://crates.io/crates/cstree
Recently I found that traversal in rowan tree can cost much time. No sure if there's a cheaper way to achieve that. Or, integrate rowan with bump allocator (bumpalo or oxc_allocator)?
I’d second Rain’s reply, but having gone from git to sapling to jujutsu, I feel like the jump from sapling to jujutsu was as big as the jump from git to sapling, in terms of “oh, this is a way nicer workflow”. I really like and miss Sapling’s interactive smart log, but I found jj’s conceptual simplicity to be more compelling than ISL. That said, VisualJJ and Jujutsu Kaizen (both listed on https://jj-vcs.github.io/jj/latest/community_tools/) might give you the ISL-style experience you’re looking for.
(disclosure: I started a jj company but I don’t have anything to sell yet.)
> Are there "central concepts" in the Jujutsu design?
I think a central concept in jj is that everything is a commit: there’s no staging index, stashes, or unstaged files, only commits. This has a few pretty neat implications:
- changes are automatically to recorded to the current commit.
- commits are very cheap to create.
- as others have already said, rebases (and history manipulation in general!) are way cheaper than in git. It helps that jj as a whole is oriented around manipulating and rewriting commits. Stacked diffs fall out of this model for free.
- Since everything is now a commit, merge/rebase conflicts aren’t anything special anymore because a commit can simply be marked as having “a conflict” and you, as the user, can simply resolve the conflict at your own leisure. While I’m sure you know already know thus, I’d rather make subtext text: in git and mercurial, you’d need to resolve the conflict as it got materialized or abort the rebase entirely.
- because everything is a commit, jj has a universal undo button that falls out effectively, for free: `jj undo`. It feels so incredibly powerful to have a safety net!
> All other Git UIs I've used have been severely lacking, but Magit has made me significantly more productive with Git, and has convinced me of the "magic of git".
I can’t speak to this personally, but I’ve had friends who are magit users tell me that jj isn’t a big enough improvement (on a day-to-day, not conceptual, basis) over magit to switch at this time. It’d be really cool to have a magit-but-for-jj, but I don’t think anyone has written one yet.
That's a great point about allocation/memory management. As an example, rust-analyzer needs to free memory, but rustc's `free` is simply `std::process::exit`.
> I think the future definitely lies in compilers written to be “incremental first,” but this requires a major shift in mindset, as well as accepting significantly worse performance for batch compilation. It also further complicates the already very complicated task of writing compilers, especially for first-time language designers.
I'm in strong agreement with you, but I will say: I've really grown to love query-based approaches to compiler-shaped problems. Makes some really tricky cache/state issues go away.
> Are they? I feel like intellisense is largely a subset of what a compiler already has to do.
They are distinct! Well, not just intellisense, but pretty much everything. I'll paraphrase this blog post, but the best way to think about think about the difference between a traditional compiler and an IDE is that compilers are top-down (e.g, you start compiling a program from a compilation unit's entrypoint, a `lib.rs` or `main.rs` in Rust), but IDEs are cursor-centric—they're trying to compile/analyze the minimal amount of code necessary to understand the program. After all, the best way to go fast is to avoid unnecessary work!
> If you wanted to argue that intellisense is a subset of compiling and it can be done faster and more efficiently I could buy that argument. But if you’re going to declare the tasks are at odds with one another I’d love to hear specific details!
Beyond the philosophical/architectural difference I mentioned above, compilers typically have a one-way mapping between syntax and mapping, but to support things like refactors or assists, you often need to do the opposite: go from semantics to syntax. For instance, if you want to refactor from struct to an enum, you often need to find all instances of said struct, make the semantic change, then construct the new syntax tree from the semantics. For simple transformations like a struct to an enum, a purely syntax-based based approach might work (albeit, at the cost of accuracy if you have two structs with same name), but you start to run into issues when you consider traits, interfaces (for example: think about how a type implements an interface in Go!), or generics.
It doesn't really make sense for a compiler to support above use cases, but they're are _foundational_ to an IDE. However, if a compiler is query-centric (as rustc is), then it's pretty feasible for rustc and rust-analyzer to share, for instance, the trait solver or the borrow checker (we're planning/scoping work on the former right now).
> I have a maybe wrong and bad opinion that LSP is actually at the wrong level. Right now every language needs to implement a from scratch implementation of their LSP server. These implementations are HUGE and take YEARS to develop. rust-analyzer is over 365,000 lines of code. And every language has their own massive, independent implementation.
rust-analyzer a big codebase, but it's also less problematic than the raw numbers would make you think. rust-analyzer has a bunch of advanced functionality (term search https://github.com/rust-lang/rust-analyzer/pull/16092 and refactors), assists (nearly 20% of rust-analyzer!) and tests.
> I think there should be a common Intellisense Database file format for providing LSP or LSP-like capabilities. Ok sure there will still be per-language work to be done to implement the IDB format.
> But you'd get like 95% of the implementation for free for any LLVM language. And generating a common IDB format should be a lot simpler than implementing a kajillion LSP protocols.
I wouldn't say 95%. SCIP/LSIF can do the job for navigation, but that's only a subset of what you want from an IDE. For example:
- Intellisense/autocomplete is extremely latency sensitive where milliseconds count. If you have features like Rust/Haskell's traits/typeclasses that allow writing blanket implementations like `impl<T> SomeTrait for T`, it's often faster to try to solve that trait bound on-the-fly than storing/persisting that data.
- It'd be nice to handle features like refactors/assists/lightbulbs. That's going to result in a bunch of de novo code needs to exist outside of a standard compiler, not counting all the supporting infrastructure.
> My dream world has a support file that contains: full debug symbols, full source code, and full intellisense data.
Rust tried something similar in 2017 with the Rust Language Server (RLS, https://github.com/rust-lang/rls). It worked, but most people found it too slow because it was invoking a batch compiler on every keystroke.
By their own admission, André is a contractor to Ruby Central. Contractors, especially under California law, have no contractual obligation of confidentiality to the other party unless there's a pre-existing agreement in place. They later admit in this "incident report" that they didn't have any legal agreements with André in place, so there's no basis for claiming André couldn't work on rv.
Samuel was an employee, not a contractor, but [California Bus. & Prof. Code § 16600](https://leginfo.legislature.ca.gov/faces/codes_displaySectio....) voids non-compete agreements—so even as an employee, he had every right to work on a competing project. There's no indication that he used Ruby Central's proprietary information to do so, and the report doesn't allege that. I have little doubt that if Samuel or André used proprietary information to develop rv, they would have already presented evidence of that.
Independent of the legalese, a "uv but for ruby" is a blindingly obvious thing to do, and Ruby Central doesn't get to lick the cookie and get upset when an independent contractor—Ruby Central's own characterization—does a thing they didn't fund.
My sourcing on this is that I run a 10-person business with employees in California. I'm not a lawyer, but I looked over enough of this paperwork that I feel confident opining on an internet forum.