I don't have much skin in the game but as a passerby, I agree that the report obviously was made with a lot of time/effort but wouldn't dramatically change someone's view of Ruby Central or assure anyone this won't happen again. This is like writing an outage postmortem without really getting to the root cause and identifying what can be done to prevent in the future.
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 agree that's likely true but I'm not sure if there are any jurisdictions finding things differently? I'm not aware of any rulings from appeals courts with broader jurisdiction but I imagine if they don't exist they will soon.
I think for brand new computers/builds that's correct but where it hit me was wanting to upgrade an existing desktop. I already have more DDR4 RAM than I need and would have been willing to purchase a new CPU/motherboard and being forced to also purchase new RAM at the same time made it too big of a price tag all at once. I just found the best zen 3 cpu I could on ebay and called it a day.
I think your point still stands overall for AMD's business though, I assume a vast majority of CPUs are purchased in new desktops?
Google operates across so many verticals that it's difficult to argue a side project is outside the scope of Google’s business and therefore Google could argue it has copyright over the work. To make it easier for engineers to keep contributing to open source, there’s a fairly straightforward path to release code through a Google-owned repository (if you look at github.com/google it is full of personal projects alongside official ones).
There is an official process where an engineer can apply to a committee to have Google waive any copyright claim. That requires additional work so if your goal is simply to publish the code as open source and you do not mind it living under the Google org, using the Google repo path is usually much faster.
Disclaimer: ex-googler, not a lawyer, not arguing whether or not the situation with copyright assignment is legally enforceable or not/good or bad/etc.
I don't think the original comment was saying this isn't a problem but that flagging it as a hallucination from an LLM is a much more serious allegation. In this case, it also seems like it was done to market a paid product which makes the collateral damage less tolerable in my opinion.
> Papers should be carefully crafted, not churned out.
I think you can say the same thing for code and yet, even with code review, bugs slip by. People aren't perfect and problems happen. Trying to prevent 100% of problems is usually a bad cost/benefit trade-off.
I agree that there is hyperbole thrown around a lot here and its possible to still use some hardware for a long time or to sell it and recover some cost but my experience in planning compute at large companies is that spending money on hardware and upgrading can often result in saving money long term.
Even assuming your compute demands stay fixed, its possible that a future generation of accelerator will be sufficiently more power/cooling efficient for your workload that it is a positive return on investment to upgrade, more so when you take into account you can start depreciating them again.
If your compute demands aren't fixed you have to work around limited floor space/electricity/cooling capacity/network capacity/backup generators/etc and so moving to the next generation is required to meet demand without extremely expensive (and often slow) infrastructure projects.
Sure, but I don't think most people here are objecting to the obvious "3 years is enough for enterprise GPUs to become totally obsolete for cutting-edge workloads" point. They're just objecting to the rather bizarre notion that the hardware itself might physically break in that timeframe. Now, it would be one thing if that notion was supported by actual reliability studies drawn from that same environment - like we see for the Backblaze HDD lifecycle analyses. But instead we're just getting these weird rumors.
I agree that is a strange notion that would require some evidence and I see it in some other threads but looking at the parent comments going up it seems people are discussing economic usefulness so that is what I'm responding to.
I think this is true with an arm mac (and would be tricky to fix that, props to the Asahi folks for doing so much) but for a lot of other hardware (recent dell/asus/lenovo, framework, byo desktops) I find Linux complete. I'm sure there is hardware out there that with struggles but I've not had to deal with any issues for a few years now myself.
I think with the right parental guidance/supervision this could be a very fun toy.
From the website it seems like a great way to generate some black and white outlines that kids can still color in. If used like that it seems almost strictly more creative than a coloring book, no? There are plenty of other ways kids can express creativity with pre-made art too. Maybe they use them to illustrate a story they dreamed up? Maybe they decorate something they built with them?
Also, some children might want to have fun be creative in ways that don't involve visual arts. I was never particularly interested in coloring or drawing and still believe myself to be a pretty creative individual. I don't think my parents buying me some stickers robbed me of any critical experience.
reply