Fifteen Electronic Devices... Is That A LOT?

Every airline’s cabin baggage regulations are subtly different. 10kg plus a personal item. 10kg INCLUDING a personal item. 8kg plus a personal item. 8kg, plus a personal item of up to 2kg. 8kg plus a laptop, umbrella, walking cane OR a personal item up to 2kg. 23kg as long as it’ll fit in the overhead locker (go British Airways!)

For a long while LOT, Poland’s national airline, would let you travel with “up to five dogs, cats, or ferrets, unless they are for commercial purposes”, which is wonderful because the collective noun for ferrets in English is “business”, as in “a business of ferrets”, so technically on LOT you could take a business of ferrets with you, but not a business ferret. Alas, this particular wording has disappeared in a recent update to their website, but I did notice a new regulation that passengers are allowed a maximum of fifteen personal electronic devices (PEDs), defined as anything containing a lithium-ion battery. You know, the ones that are in literally every single device which exists these days but which very occasionally go on fire so airlines are understandably a bit flummoxed about exactly what to do about them.

It’s not readily apparent from their website whether that’s fifteen PEDs per passenger total, or just in checked baggage (and I didn’t think you could put li-ion batteries in the hold at all, but apparently that’s just for actual spare batteries and powerbanks now, and doesn’t apply to devices containing a battery)… but fifteen’s a lot, right?

Well… actually, no. Not if you’re a massive nerd. Here’s my inventory for Build Stuff in Vilnius:

1. MacBook Pro laptop
2. Framework Windows laptop
3. iPhone
4. backup iPhone
5. Smartwatch
6. Powerbank
7. Samsung Galaxy tablet
8. XVive in-ear monitoring receiver
9. XVive in-ear monitoring transmitter
10. Wireless guitar transmitter
11. Wireless guitar receiver
12. Anker SoundCore noise-cancelling headphones
13. Sony C100 wireless earbuds
14. JBL portable Bluetooth speaker

That’s the standard inventory for any event where I’m doing a technical presentation and playing a show with Linebreakers - fourteen devices! Nice to know I could add a Kindle to that lot and still be within the regulations.

I note with some amusement that if I replaced the Sony earbuds with Airpods Pro or similar, that would technically be *three* PEDs, since each earbud has its own battery and there is a third battery in the charging case. So better not do that, then.

Is a 100% Discount The Same As “Free”?

For the last year or two, I’ve been giving a talk at conferences around Europe about free software. It’s called “open source, open mind: the cost of free software”, there’s a couple of recordings of it up on Youtube if you want to check it out, and, like a lot of my conference talks, it’s a mix of history, case studies, and my own experiences working in tech.

One of the perennial challenges facing the craft of software development is that I think our industry has a tendency to attract people who like to create. I know dozens, probably hundreds, of people who became software developers because they enjoyed the activity of writing code, of sitting down and creating a solution to a problem. I don’t know anybody who got into tech because they enjoy reading code - most of us still don’t; reviewing code is way less fun than writing it. This tendency for software developers to ignore prior art because, well, gosh, it’s great fun reinventing the wheel over and over again - it’s one of the reasons I spend so much time talking about computer history. A few years back somebody was very excitedly telling me about something called a microSPA; a SPA is a single-page application, and a microSPA is a very small single-page application; an individually deployable unit containing HTML, JavaScript, CSS… that’s right, they’d reinvented the web page. And it only took twenty years.

I think it’s important to talk about the history of free software because I keep seeing the same patterns playing out, over and over again - and every time they do, somebody ends up burning time and brain cycles on solving a problem that we already solved, and I wonder what new and fascinating things they could have created instead.

I want to talk about two of these patterns in this video. First - let me know if this sounds familiar to you: somebody creates some free software. Free, as in, it doesn’t cost any money. It’s out there on the internet and you can download it and use it and even incorporate it into your work projects - projects that make your company money. And you do, whether that’s by installing a package from NuGet or npm, or connecting to some sort of online API, or cloning their github repo and building it yourself.

What you don’t see is the flipside of that. The person who created that library? They’re doing - and sharing - that work because at that point in their own life and career, that makes sense to them. Richard Stallman’s Free Software Foundation has popularised the idea that giving away your source code is some sort of lifelong ideological commitment, a fundamental part of somebody’s identity - but really, that’s not how any of this works. What normally happens is somebody’s working in some kind of agency or consultancy, they create a library which gets used internally across multiple projects for different clients, there’s a conversation about making the source code available - which, at that point, makes a lot of sense; clients get that code under a public license, it gives the agency something good to say to candidates when they’re recruiting, and maybe they’ll even get community contributions that add features or fix bugs. Everybody wins.

Then something changes. Somebody leaves. The agency gets acquired. For whatever reason, the people that used to maintain that project aren’t in a position to do that for free any more - and so the logical thing to do is what a lot of open source projects and packages have done in the last few years: to say to the consumers, the people and companies who are using that code to make money, “hey, in order for me to keep doing this, I’m going to need to get paid somehow. Seeing as donations haven’t worked, and consulting has pulled me away from working on it, I’m going to try charging for the software itself, so the next version won’t be free”.

This usually splits the community in two. In one camp are the ‘keyboard warriors’, the folks who like to express their outrage on social media; in the other camp are the people who understand software licensing, budgets, compliance - and the cost of replacing or rewriting something which already works. There may be some overlap, but from talking with maintainers who have done exactly this, most of the big corporate users will quietly sign up without making a lot of noise about it, and the people on Twitter and Reddit shouting about betrayal and open-source “rug pulls”… well, they were never going to pay for anything anyway.

There’s another factor in all this, of course. I think it’s absolutely right that companies that get substantial financial benefit from the use of free and open source software should contribute to the sustainability of those projects. I recently found a thread on X which linked to a bug filed on ffmpeg’s issue tracker in May 2023, which included this absolute barnstormer of a comment:

Hi, This is a high priority ticket and the FFmpeg version is currently used in a highly visible product in Microsoft. We have customers experience issues with Caption during Teams Live Event. Please help,  

Microsoft. Microsoft Teams. It would be nice to think that Microsoft Teams could come up with a more constructive way of engaging with the maintainers of ffmpeg than expecting a request for free support to be treated as a ‘high priority ticket’, but unfortunately this sort of interaction between large corporations and small open-source project teams isn’t remotely unusual.

We’re not all Microsoft, though… and that’s where the one-size-fits-all model breaks down pretty quickly. The sort of licensing fees that are a drop in the ocean to big tech companies could be a dealbreaker for a startup that’s just getting off the ground - and for projects which are themselves free-as-in-free-beer, for student and hobby projects; those projects are never going to be able to justify hundreds or thousands of dollars in license fees.

The problem is that the alternative to paying for a license tends to be “oh well, if we can’t use that one maybe we can just build our own”… which is rarely a good idea in terms of the quality of the software, but also, if you’re at an early stage startup or a small-to-medium business, you should be focusing on your mission, working on the features that are strategic differentiators for your product or service, not spending time building authentication and telemetry and data persistence and all the other stuff that’s already been solved over and over again.

Now, none of this is a new idea. The first project I know of that switched from a completely free license to something more restrictive was ServiceStack, which switched in 2014 from a BSD license to a hybrid commercial license. Their approach was interesting: free licenses for genuine solo projects, defined as anything where a single person was the sole author, contributor and copyright holder of all the code in that project. They offered free licenses for projects that in turn published their own code under a compatible open source license - and if you didn’t qualify for a free license? $299 per developer for small organisations - fewer than ten employees; $999 for large organisations. That was, and is, a per-developer, one-time, perpetual license - you get a year of maintenance and upgrades, and any new releases during that maintenance period, you can run those releases forever.

The company I was working for had half-a-dozen developers working with ServiceStack at the time, but we had over fifty employees, so for us upgrading from the BSD-licensed ServiceStack 3 to the new licensing model would have cost six thousand dollars. The budget meeting about that one didn’t get very far - and I get it; although we were using APIs for all kinds of internal stuff, they weren’t a key part of anything that actually generated revenue, and I didn’t know back then about accounting models like Cost of Delay, which might have given us a way to calculate the value of the time we saved by sticking with it instead of switching to a different framework or building our own.

ServiceStack is a really useful case study, because they did this ten years ago. With a whole load of high-profile projects switching their licensing over the last few years - IdentityServer, Redis, Terraform, and more recently AutoMapper and Mass Transit - there’s been a very predictable reaction; community backlash, a fork of the last version of that product that was published under an open license, and a lot of folks asking what happens next? Well, ServiceStack has gone from strength to strength, shipping a steady stream of new versions and features. It’s a solid, sustainable, commercially viable product. The community fork of the last BSD codebase? That was NServiceKit, which was very exciting for about six months before enthusiasm ran out. It’s now been a decade since the last commit. I assume because its creators realised what every fork will find out sooner or later: if you fork a free project because it’s going commercial, all the people who are happy to pay for licenses, support and maintenance will go with the upstream project, everybody who expects support and maintenance to be free will beat a path to your door, and you’ll be expected to maintain feature parity with the project you forked and do it all for free out of the goodness of your heart.

Now, one thing I think ServiceStack got wrong was to offer free licenses for small projects, defined as projects with fewer than 10 defined service operations, fewer than 10 mapped database tables, and a limit of 6000 requests per hour on their Redis client when running without a license, those kinds of restrictions. 

I applaud the objective here - hey, use our software while you’re getting started, and pay for it later once you need the extra scale. But I think those kinds of limitations in any kind of software aren’t a great idea, because they put a  financial roadblock in the way of what should be an architectural decision. Imagine you’re working on a project, you’ve got a team of five developers building a new feature and turns out the best way to deliver that feature is going to require mapping one more database table - except, oh crap, we already used our ten free tables. That eleventh table is going to cost you five thousand bucks - and meanwhile, if a billion-dollar Fortune 500 company is only using nine database tables, they’ll still qualify for free licensing.

There’s a bunch of different ways that other projects have approached this:. 

Duende’s Identity Server, an open source authentication framework for .NET, has a pricing model based on the number of client IDs you’re running - there’s a startup license that’s fifteen hundred dollars a year for up to five client IDs, then five hundred a year for each additional client ID up to fifteen, where it switches to the business license, nine thousand dollars for fifteen IDs, everything in the startup license, plus some additional features like automatic key management. They also have a community edition that’s free for companies with under $1 million of revenue and under $3M of capital.

Chris Patterson also seems to be going with something like this for MassTransit, with a free tier for organizations and nonprofits with up to $1 million of revenue or expenses

Just so we’re clear, a million dollars sounds like a lot of money - and yeah, to the vast majority of the people living on this planet, it’s a life-changing amount of money - but when you’re a tech start-up, a million bucks really doesn’t go very far. Hire some engineers, bring in the hardware and infrastructure for them to do their jobs, pay your lawyers, your insurance, your rent … and it’s gone.

I think this is why we’re seeing some projects raising that a bit higher. For example, Jimmy Bogard set the level for his community edition of AutoMapper to be free for companies up to $5 million of revenue and $10 million of capital. 

I think the original version of these various free offerings was Microsoft’s BizSpark programme way back in 2008, which provided free and heavily discounted access to Microsoft developer tools and Azure hosting to startups for the first two years of operation - the idea being, I assume, that within two years either the startup is generating enough revenue to pay for those services, or it’s done what most startups do and quietly shut down because it ran out of money; that programme has evolved over the years and today is called Microsoft for Startups, and - this being 2025 - offers free AI and Azure credits to companies which are just starting out.

Particular also just put out their version of this for NServiceBus, using the more generic term of “financials” to cover revenue, capital, and expenses. They set up this “sliding scale” which starts with the same 100% discount for organizations up to a million USD of financials, just like Duende and MassTransit; but when you go past that, you don’t start paying full price right away. Instead, the discount goes down just a bit to 90%, and passing two million it’s reduced to 80%, at three million it’s 60%, at four million it’s 20%, and only when you pass five million dollars you pay full price.

Now, full disclosure: I know a lot of the folks at Particular, we’ve collaborated on a few things over the years, they gave me a heads-up that they’d be announcing this, and they know what’s in this post ‘cos I sent them the draft before I published it, so this isn’t an unfiltered reaction piece… but in another way, it kinda is, because I think this is fantastic.

First of all, it’s an interesting new take on what everybody else has been doing. Second, it solves a real problem for growing companies - you’re not going to suddenly find out one day that your last quarter accounts have pushed you over a threshold and you’ve gone straight from zero to full cost. And third, for existing small businesses using NServiceBus, they’re about to get a nice discount on their NServiceBus bill.

Another detail I think is worth mentioning was that all of these projects excluded “priority” support from their free and discounted offerings - which I think is entirely justified. Good support takes time and expertise, meaning that it can usually only be done by the project maintainers - the very people whose time is stretched thin and are struggling to get to financial sustainability. That’s why I don’t think anybody who’s getting the benefits of fully-discounted licensing should expect to get the same degree of support as the organisations that are paying full price.

Point is, there are organisations with money - whether that’s revenue, assets, or investment - and not just the big brands, but the countless mid-sized banks, insurance companies, and even government entities. They can, and they should, be paying for the stuff they use. These are the last people who are going to complain about “rug pulls”. Professional developers in these contexts clearly explain to their bosses and clients, “so, this thing used to be free, and we used it a bunch, and from the next version it will cost this much. Replacing it with something else that’s free will take roughly this many hours. What do you want us to do?” A rational boss, or client, will tend to accept a reasonable license cost rather than incur the risk of a rip-and-replace; as Nick Chapsas said in a recent video:

You sort of should assume you take a risk by just using something that’s free out there. There’s no contract [covering] … what’s going to happen in the future.

But for all of those organisations that don’t have that kind of money; the startups, student projects, open source, small independent agencies, not to mention the large parts of the world where local market economies operate on an entirely different scale - these discounts can be just what they need to continue to build upon solid foundations, meaning they wouldn’t need to change anything when the open-source projects they use commercialize - so no “rug pull” here either.

A bunch of us have been talking about how we can take these things forward and enable more open-source projects to achieve sustainability. We’ve seen how standard OSS licenses like MIT and BSD have helped accelerate legal acceptance of open-source software, so we think some kind of standardization around commercial terms and discounts could be helpful. What exactly that would look like is still being discussed, but my hope is that by putting out this video describing some of these approaches, the next OSS maintainer will think to themselves, “yeah, I can do this too”. 

One final thing I’d like to add: I see occasional online comments about projects “going closed source”… well, that’s just not true. Every single one of the projects and companies I’ve mentioned in this video remains committed to sharing the full source code for all their products, so that developers who are relying on that code can download it, build it, step through it in the debugger if they need to - that’s a big part of “open source”; the ability to obtain the source code, study it, modify it if you need to, and even maintain your own fork of it if you don’t want to rely on the original vendor. All we’re saying here is that if you’re using these projects in a commercially significant context, you should expect to pay something towards their maintenance and future development - and if some sort of scalable discount model makes it easier to reach that point, I think that’s a good thing for everybody involved.

Choosing the Right Path

Srijan Singh pinged me on LinkedIn earlier today with a question:

I’m in my early career as a backend dev at IBM, and something I often wonder about is choosing the right path: whether to stick with a big company and learn deeply, or test myself in a startup environment (remote vs in-person adds to the mix too). Since you’ve navigated such diverse experiences, I’d love to hear how you’d approach that decision early on.

I quite enjoy getting these kinds of questions, but as Scott Hanselman wrote way back in 2010:

 If you email someone one on one, you’re reaching that one person. If you blog about it, you get the message out on the web itself and your keystrokes travel farther and reach more people. Assuming you want your message to reach as many people as possible, blog it. You only have so many hours in the day.

So here’s my answer to Srijan’s question, as a blog post.

Let’s start with the simple answer, which is how I did approach that decision early on… I didn’t, really. I was lucky enough that I didn’t really have to think about it. I loved working with computers, writing code, and building websites, and if I was getting paid money to do that I was happy. I landed my first graduate role in 2000, via one of my housemates who was working as a recruiter; three years later one of our clients, Spotlight, asked me to work for them full-time; fifteen years after that, I got head-hunted by Skills Matter to become their CTO; they went bankrupt in 2019, I set up my own company, Ursatile, and I’ve been independent ever since. To put this another way: I’ve had exactly two job interviews in my life, and one of those was to stack shelves in a grocery store when I was sixteen years old.

That probably doesn’t help, right? 😆

Looking back over 25 years of working in software, though, I think there are three things that matter:

• The problem. Are you helping people? Are you making somebody’s day better? Are you building something that’ll make your end users happier? Or is your entire working life about making the CEO’s stock go up another point?
• The people. Who are you working with? Are they competent? Are you learning from them? Do you enjoy their company? Do they respect your ideas?
• The process. How does stuff actually get done? Everything from prioritisation and planning to what text editor you use. I enjoy working with some technology because it makes it easy for me do good work. I do not enjoy working with some other technology, because it makes it hard for me to do good work.

You don’t need all three. I’ve had bits of my career when I’ve been working with awesome groups of smart, kind people, using great tech to solve cool problems. I’ve also had bits of my career when I’ve been using painful tech to solve pointless problems, but the people made it worthwhile - and, occasionally, periods where I honestly didn’t care for the people or the problem, but was learning so much along the way that I probably stuck around longer than I should.

Think about longevity. You’re building solutions, relationships, and skills. Will the things you’re building last for a decade, or will they be obsolete by the end of the year? Can you take those things with you out into the wider world, or do they only have value in the context of your current role?

Remember to take stock once in a while. You might find the job that used to tick all three boxes is down to two, and then one… and when you’re down to one, you’re in danger, ‘cos if that one disappears too… well, congratulations. You’re stuck using tech you don’t enjoy to solve problems you don’t care about with people you don’t like.

Now, obviously there’s a huge amount of context to consider here. The tech jobs market is the worst I’ve ever seen; more of my dev friends are out of work right now than at any point since the first dotcom bubble, 25 years ago. If you’re supporting a family or paying off debts and you have a steady paycheque, maybe just keep your head down, keep doing what you do, wait for things to pick up. But if you’re early in your career, you’ve got a bit of financial security and you’re unhappy with how you’re spending your working days? Do something different. Bored of working in the enterprise? Find a startup. If you’re burning out working in a startup, get a comfortable, predictable job in a big company. If you’re remote, and tired of being at home all the time, find a job with a nice office; if the commute is making you miserable, try remote. When you try something, give it at least a year - but if you’ve lasted a summer and a winter, learned the ropes, learned the industry, and you’re still miserable? Probably time to move on.

Really, though, the important question when it comes to career progression isn’t “where do I see myself in five years”, it’s “am I going to quit my job today?” That’s the question that actually makes things happen. If the answer’s “hell, no, I’m happy”? Awesome. Go to work. If the answer’s “yes, today’s the day!” - well, good luck with it.

But if the answer’s “I don’t know”? Well, time to gather some more data.

On The Road Again...

I’ve spent most of the summer so far writing a new course; if you follow me over on BlueSky - and you should - then you’ll have noticed I’ve been posting - skeeting? bleeting? I still don’t know what to call posting on BlueSky. Let’s go with bleeting. I’ve been bleeting about CSS a lot, because my new course is CSS for Software Engineers. The video course is going to be available on Dometrain later this year, I’ll be running it as a workshop at various conferences, and I have a funny feeling there might even be a book at the end of it… but that’s taking up pretty much all my time, not to mention brain capacity, and hasn’t left a whole lot of time for YouTube videos and stuff.

But, it’s nearly September (yeah, really), which means it’s nearly conference season again, and I’m going to be bouncing around Europe for the next few months talking about all kinds of things - machine learning, text encoding, Rockstar, open source, and, yep, CSS.

Now, here’s the thing. When folks like me get invited to speak at these kinds of events, the organisers really appreciate it when we make a bit of noise about it, post it on social media, blog about it, make videos… and I get it; marketing is tough, every bit of coverage might help shift a few more tickets, and the algorithms that drive social media apparently love short form portrait videos… but, y’know, I’m forty seven years old, I listen to Bon Jovi and I still don’t really understand what TikTok is for; somebody like me making a video on my phone about a .NET developer conference and hoping it’ll go viral is… I believe they call it “cringe”.

But then I remember a few years ago I was in Tartu, in Estonia, where I was giving the keynote at digit.dev, and somebody recognised me in the street from my YouTube videos and we got chatting… turns out they’re a developer, they love code, they really liked my conference talks, and they had no idea that I was the keynote speaker at a multitrack international conference taking place right in the city where they live. And Tartu’s not a big place; it’s got about 100,000 people.

So here’s the deal. I’m going to tell you where I’m going, on the off-chance that you’re local, and you have some training budget left, because it would really suck if there was an awesome event happening right there in your home town and you didn’t know about it.

If you want a whole “ten reasons you can’t afford to miss OpenTechDevConDays 2025”… well, nah. Not really my jam. They have marketing people for that.

For what it’s worth, I do try to make sure that every event I’m involved with is excellent; I put a huge amount of work into preparing talks and workshops, I bring stickers to give away, and I try to make sure I have as much time as I can to meet people, hang out and chat about what you’re all working on.

So here’s where I’m going to be. I’m obviously not expecting any of you to come along to all of these - although I’ll be very impressed if you do - but if I’m going to be in your neighbourhood, and if you can persuade your company to buy a ticket, then come along and say hi.

I did mention I’ll be giving away Rockstar stickers, right?

September 8-12th I’ll be at NDC Copenhagen, where I’m running a brand new workshop about all the amazing things modern CSS can do. I’ll be giving a talk about algorithms and why they’re not as scary as they look, and probably eating quite a lot of barbecue at Warpigs.

September 25th I’ll be Edinburgh at ScotSoft 2025 talking about plain text: weird and wonderful stories about teletype machines, Hungarian Scrabble, how emojis actually work, and what “PIKE MATCHBOX” has to do with driving in the Soviet Union.

October 3rd I’ll be in Dordrecht in the Netherlands with Fronteers; that one’s a one-track evening conference, so should be a lot of fun; we haven’t finalised all the details for that one yet, but keep an eye on https://www.fronteers.nl/ for more news.

October 9th + 10th, I’ll be in Riga for Zabbix Summit. Zabbix is an open source observability and monitoring platform, so the event’s all about infrastructure, automation and devops; I’m going to be talking about the history and future of free software and how we might be able to create a truly sustainable model for open source development.

Then I’m in Portugal for two weeks; October 13-16 is the Azure Developer Summit in Lisbon, a brand new event organised by Microsoft in partnership with NDC and Techorama, all about Azure, AI, .NET, C# - and then 20-24 October it’s NDC Porto, which has a different format this year; instead of one-hour conference sessions it’s all hands-on workshops. I’m doing two days about modern CSS, plus a session about building a ray tracer in JavaScript, and another one about how to build your own programming language using C# and .NET and parsing expression grammars.

Then I’m home for two days, then a Eurostar to Rotterdam and on to Utrecht, where by a happy coincidence Techorama is in town the same week as Tweakers Summit. ***Monday 27th October*** I’ll be at Techorama with a one-day Introduction to Distributed Systems with .NET workshop, Tuesday 27th I’ll at Techorama in the morning and then heading to DeFabrique to close the Tweakers Summit, then I’m back at Techorama on Wednesday.

And then November 5-7 I’m at Øredev in Malmö, where I’ll be telling the story of how I built a Rockstar interpreter in web assembly using C#, and rocking the party stage with The Linebreakers.

Oh, and if you’re thinking “wow, that’s not nearly enough travelling, this guy isn’t even trying any more”, I’m also going to the Euroblast festival in Cologne at the end of September, and heading to Yorkshire for the Whitby Goth Weekend at the end of October. Not performing or anything, just going along to watch bands and have fun. You know. Like a normal person.

So that’s, what, nine tech events - and two music festivals - in seven countries in two months. It’s going to be . Come along and say hi.

Right now, though, I gotta get back to writing about how CSS flexbox actually works, which turns out to involve way more mathematics than you might think.

CSS Has 239 Different Ways To Make Something Blue

I’m making a new video course for Dometrain at the moment, and it’s all about CSS - one of the three pillars of the open web, along with HTML and JavaScript. I love CSS, I’ve been working with it literally since it was invented, but I absolutely understand why so many developers don’t enjoy working with it.

CSS has had to incorporate conventions and standards from a wider range of disciplines than any other mainstream technology. Modern CSS incorporates ideas from mechanical typesetting dating back centuries, conventions around information design from hundreds of years of printing and publishing, fifty years of innovations from digital publishing and computer graphics, twenty years of getting stuff wrong on the web while we were still figuring out how to get it right - right up to things like how to account for the “dynamic island” on the latest iPhone handsets.

To say it’s accumulated a few idiosyncrasies along the way would be an understatement. Yesterday, while putting together the module about how the various colours models work in CSS, I found myself wondering how many different ways there are in modern CSS to give a box a blue background.

I got to 239. Two hundred and thirty nine different ways to say “the box is blue”.

You’ve probably heard of named colours (color: blue;), and hex codes (color: #0000ff). Hex codes can also be written as three digits (#00f), four digits (#00ff), and eight digits (#0000ffff).

Then there’s the rgb() function, which can take each colour component as a decimal or as a percentage. There’s hsl(), which takes hue, saturation, and lightness, along with a bunch of new colour models - hwb(), lab(), lch, oklab() and oklch() - all of which also take a hue component.

Except hue in CSS is an angle - the colour’s position on a colour wheel - and CSS already has a unit system in place for angles, that’s used for rotations and transformation, so the colour models just reuse that. Which means you can write the hue component as degrees (with or without deg), radians, gradians (the cursed unit. 400 grads in a circle. Why does it even exist? I don’t know.), or turns. So if any colour specification involves hue, there are five different ways to write it.

Add in two different ways to specify alpha transparency - / 100% and / 1.0 - and you end up with well over two hundred different ways to say “the box is blue”… and this is just using the modern CSS colour syntax; we’re not even getting into the legacy rgb() and hsl() function syntax, their aliases rgba() and hsla(), or any of the wonderful things you can do with calc() and relative colours.

OK, let’s be fair here. If the language designers hadn’t reused CSS angular units for hue, we’d be looking at more like 40, maybe 50 syntax variants. Pick a lane for how you want to specify transparency, you’re down to 20 or so. You’re very unlikely to use the LAB or LCH colour models in production unless you know exactly what you’re doing, so that’ll chop it down further; in reality, you’re not going to encounter more than handful of these variants, and the vast majority of sites out there just use hex codes for everything.

But, y’know, if you’ve got the whole chaotic evil vibe going on, why not spec all your colours as oklch, lightness and chroma as arbitrary decimals, hue in grads, and give everything an alpha channel that’s randomly a percentage or a decimal, even for colours which are fully opaque?

I think you’ll all agree that color: blue; looks kinda dumb, but color: oklch(0.452 0.31 292grad / 100%); is clearly the work of a genius.

Check out the whole list over at https://dylanbeattie.net/miscellany/blues.html