The Changelog: Software Development, Open Source - Yet another open source rug pull (News)

Episode Date: June 3, 2024

A popular open source iOS authenticator app goes rogue under new ownership, Andreas Kling steps back from SerenityOS & forks Ladybird, Vhyrro takes a thought-provoking try at a "static effect system", Matt Bessey is over GraphQL & Marc-Andre Giroux still likes GraphQL sometimes (in the right context).

What up, nerds? I'm Jared, and this is Changelog News. For the week of Monday, June 3rd, 2024, I poked fun at Adam on our You Have How Many Open Tabs? episode a while back, but never again. We now have cold, hard evidence of a Firefox user who kept 7,400 tabs open for over two years. Yes, you heard that right. 7,400 tabs. Yeah, but your scientists were so preoccupied with whether or not they could, they didn't stop to think they should.

Okay, let's get into the news. But first, a quick correction from last week. The article I covered about clear, readable code was written by Leonardo Creed, not Jordan Cutler. Sorry about that, Leonardo. Okay, now let's get into the news. Ravio OTP app quietly changes hands, loses passwords. In yet another unsettling open source sustainability failure, Ravio, a popular open sourcesource iOS authenticator app that syncs your one-time passwords across devices, was quietly transferred from its original creator

to a company called MoBeam. After about 10 months of zero public commits, the new owners shipped an update that deleted people's 2FA codes, and according to one angry user review, quote, it's ransomware. Unless they pay, their 2FA codes are gone. Some users have had their codes gone forever, end quote. I was tipped off to this ordeal late last week by friend of the log rderrick, who was previously a happy user of Ravio. rderrick told me, this is a super critical app. I mean, it holds your OTP. It doesn't get as critical as that. This is an example of how not to do open source management, end quote. Since then, Mobeme's developers have removed the issue tracker where everyone was complaining from the GitHub repo and closed all open PRs, including one that would inform users about the

data loss and the paywall. Say it with me. Rugpole? Not cool. Ladybird spreads its wings, targets Linux and macOS. Andreas Kling, creator of SerenityOS and its Ladybird browser, is forking Ladybird and stepping down as SerenityOS BDFL. Andreas says, quote, Until now, the project and its community have existed in a state with two groups sharing all resources and infrastructure. One group who mostly cares

about building a desktop OS and another group who mostly cares about building a cross-platform web browser. In the past, there was enough overlap between interests that it made sense to share everything, but these interests have slowly grown apart. I've decided it's time to make a big change. To streamline development of Lady Bird, I'm forking it off from SerenityOS into a new, separate, top-level project. End quote. This change, while difficult and surely emotional for Andreas, seems like a healthy one for both projects. Ladybird gets to spread its wings and fly on more mainstream operating systems like Linux and macOS, and Serendios is now community-driven, no longer distracted with a web browser effort,

and hacking on fun software with friends is once again its main focus. Moving beyond type systems. The linked article is a thought-provoking look at what a static effect system is, what it might look like, and how it could be beneficial to programming languages moving forward. Quote, To this day, we are pretty used to having

all side effects under our control or having no side effects. What if we could strike a balance? The article's author, Vero, goes on to explain how Rust has already made a move in this direction, but we don't think about it in explicit terms as a static effect system. What even is a static effect system though? Vero says, quote, a static effect system would be something akin to Rust's borrow checker, but for effects. Instead of being able to interact and handle effects through functions, the programming language instead has an effect checker

that statically analyzes the program and makes sure that everything holds. This would mean making sure that all effects are annotated properly and that no side effects occur where they shouldn't. The remainder of the post focuses on implementing a static effect system. It's a deep dive, but a good read. And food for thought. Vero finishes with this. Quote, I haven't been able to find any obvious pitfalls with the idea though.

Hence, I shared it on this blog. Hope I caught your attention. I encourage all theorists to play around with the idea. Let's do some sponsored news. AI for incident management is here. Fire Hydrant's Robert Ross says, quote, over the last five years, we've seen our customers run 583,954 incidents more efficiently thanks to a shared workspace, powerful runbook automations, and auto-capture data. Yet, despite a great deal of progress, incident efficiency hasn't achieved peak potential. We talked to a lot of folks that are still stuck in the muck. New responders

struggle to get up to speed quickly, incident commanders wade through post-incident drudgery, and knowledge silos prevent comprehensive improvements. But there's a way for all of us to feel like we're running incidents with a cheat code, AI. End quote. There's no shortage of things you can sprinkle AI into, but Robert and his team at Fire Hydrant took a thoughtful approach and explicitly chose features that would meaningfully improve the responder experience and had the potential to shave hours of work off every incident. The best part? All FireHydrant accounts have immediate access to the new AI functionality. Follow the link in the newsletter to find out exactly what they're up to.

Why, after six years, I'm over GraphQL. Matt Bessie writes, quote, GraphQL is an incredible piece of technology that has captured a lot of mindshare since I first started slinging it in production in 2018. You won't have to look far back on this rather inactive blog to see I have previously championed this technology. After building many a React SPA on top of a hodgepodge of untight JSON REST APIs,

I found GraphQL a breath of fresh air. I was truly a GraphQL hype train member. However, as the years have gone on and I have had the opportunity to deploy to environments where non-functional requirements like security, performance, and maintainability were more of a concern, my perspective has changed. In this article, I would like to take you through why today I would not recommend GraphQL to most people and what I think are better alternatives. End quote. Matt goes on to provide a long list of issues that he has with GraphQL in excellent detail. Of those, this is the one that's most concerning to me. Quote, in my experience in a mature GraphQL code base,

your business logic is forced into the transport layer. End quote. Yo, keep your business logic out of my transport layer. Thank you very much. Why, after eight years, I still like GraphQL, sometimes in the right context. Matt's post was a conversation starter. Mark Andre Garou responded with his own opinion after also using GraphQL for a long time. His major point is one I don't see discussed often. Use persisted queries. Quote, persisted queries are basically essential for building a solid GraphQL API. If you are not using them, you're doing GraphQL on hard mode. It's not impossible,

but it leads to difficult problems. Some of them discussed in this post. After eight years of GraphQL, this has only gotten more and more important to me. Persist all queries as soon as possible. In your GraphQL journey, you'll thank yourself later. End quote. The problem with persisted queries is that they aren't an option for public APIs, but it sounds like most people are using GraphQL for non-public APIs anyhow. Another quote, I can feel the pain of the author when it comes to building public GraphQL APIs. It's not easy, but his post in general never really addresses a very common use case for GraphQL, which is an internal API for known multiple clients. In this context,

using persistent queries is easy and solves a lot of the problems the author encountered in their journey. After eight years of GraphQL, I still enjoy the decoupling a GraphQL schema offers between server-side capabilities and client-side requirements, but am aware of the trade-offs when picking it as a technology. End quote. So, where we're ending up is, it depends? It does depend, doesn't it? I leave you this week with Gall's Law, which states, A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched

up to make it work. You have to start over with a working, simple system. That is the news for now, but we have some great episodes coming up this week. Mark Rusinovich, Eric Boyd, and Nihabatra on Wednesday, and we're back playing the award-worthy Pound to Find game show on Friday. Have a great week. Leave us a five-star review if you dig what we're up to, and I'll talk to you again real soon.