Discover more from The Engineering Value Chain Revolution
EVC #2: Don't poke the open source bear, Quantum Country, and Firefox migration headaches
There’s a reason why “Don’t poke the bear" is a saying. On January 19th, Elastic published a blog post announcing some of the reasoning behind the licensing changes for ElasticSearch and Kibana, condemning Amazon for “ethically challenged” behavior towards their open source work. On January 21st, Amazon responded saying that to keep the project truly open source (defining what is canonically open source is a whole issue in itself, but I digress) they will fork ElasticSearch and Kibana. Those forks will be licensed under Apache 2.0 rather than Elastic License / SSPL.
I think both Elastic and AWS are partially wrong in this situation: if you decide to build an open source company, this is part of the tradeoff you have to accept. If you’re AWS, you shouldn’t fork a project, host it, and then say it’s in “collaboration” with them if they are not aware of it. It’s going to be interesting to see how this affects the Elastic roadmap, and how far the AWS fork will deviate from the current state of the product. Grafana started as a fork of Kibana, so the best-case scenario for the community is another great OSS product being born from a fork!
If you’re interested in learning more about licensing, I recently wrote a history of software licensing starting from the 70s, covering that time a paper tape of BASIC was stolen at the Homebrew Computer Club, all the way to today. I haven’t published it anywhere yet, but you can see my Notion draft here if you’re curious!
Porting Firefox to Apple Silicon: a very neat article on what it took to update Firefox to support Apple M1’s architecture, including how they had to resort to LinkedIn to get whitelisted by an anti-virus provider after their support channels went silent. For the nostalgics in the audiences, the author Gian-Carlo Pascutto was one of the main contributors behind foobar2000. Thanks Garf :)
You don’t need Kafka: Vicki Boykis wrote a great post on overarchitecture and how engineering teams fall prey to hype cycles, especially when new developers see them glorified on forums like Hacker News.
Quantum Country: an interactive introduction to quantum computing and quantum mechanics. It requires some basic linear algebra and math knowledge, just FYI!
An Analysis of Privacy on the App Store: an in-depth breakdown of how Apple’s app privacy details are structured on the backend, as well as some aggregate statistics. Very nice of them to use clearly defined identifiers like DATA_LINKED_TO_YOU. Quick stat: The median amount of non-app data trackers in free apps is 3, compared to 0 for paid apps. Facebook? 151. Yikes.
Matt Caulfield is the founder of Oort, the company behind the Oort Cloud. Their goal is to build a decentralized security fabric that allows businesses and systems to connect safely with each other. Matt previously spent 10 years at Cisco focusing on edge computing; you might have also seen him give a talk at KubeCon on multi-cluster topologies.
What’s one productivity hack that you really love? (Automation, dotfiles tweaks, etc)
I don't know about automation - I still prefer vi and bash as my development environment - but I can think of a few techniques/habits that have had a material impact on my personal productivity...
Sunday night planning - I can't recommend this one enough. I spend Sunday afternoon or Sunday evening, before the week starts, reviewing my calendar and todo list and prioritizing my time accordingly. Sunday is also a good time to step back and think strategically - are we going in the right direction? what's working? what do we need to change? During the week I just follow my calendar. Coming from a software background, I'm inspired by the idea of committing to weekly sprints. It helps me compartmentalize what is otherwise an infinite amount of work.
Second shift - this one I would not recommend but it has had the biggest productivity upside for me. I am a night owl and there is no hour in my day (or night) that is more productive than 1 AM. I'm regularly up late to avoid the bustle and meetings of the day. I catch up on the "real work" while the world sleeps. When I was in college, my father framed an excerpt from "The Ladder of St. Augustine" that I keep in my office. The heights by great men reached and kept were not attained by sudden flight, but they, while their companions slept, were toiling upward in the night.
Ignoring my inbox - tuning out the flurry of emails is the other simple change to my daily habits that's resulted in far more hours of productivity. Unfortunately, responsiveness is a key trait that investors and customers depend upon. I'm still working out the right priority system to accommodate everyone, but it's a work in progress. If you're looking for quick fix, calendly has been fantastic at reducing email round trips.
What’s the latest product your engineering team has adopted at work?
From a hosting perspective, we decided to adopt Google's Cloud Run instead of going directly to Google Kubernetes Engine (GKE) for hosting our containers. We've been pleasantly surprised by the experience. It helps us avoid the overhead of managing k8s deployments while setting us up to move there later.
What technology/architecture are you the most excited about trying? What about getting rid of?
My team will tell you that I keep bringing up graph databases. I'd love to find a simple, scalable, and cost-effective option that we can incorporate into our architecture. Getting rid of Kafka (even though we haven't fully deployed it yet) is high on my list.
What’s one side project you started but never finished?
I started building a distributed C compiler (that I was calling DistriC) that could take a piece of code, parallelize it, and then distributed it across multiple hosts automatically. It was a cool idea and taught me how hard it is to rely on a shared memory model across an unreliable network. It's much easier to build code that is intentionally built for distributing across systems. Never finished, but I think of it often.