What should that next version be called? Modern software broadly bifurcates into two competing standards; SemVer and CalVer.

SemVer

Semantic Versioning is usually in the form 1.2.3, the last digit is usually for minor bug fixes, the second digit for new functionality, and the primary digit for big and/or breaking changes.

The semantics are pretty loose. There's no real consensus on when a new "primary" number should be issued. There are two main weaknesses:

1. The numbers might not be decimals. Is V1.29 newer or older than V1.3?
2. There's no semantic information about when the software was released.

Which leads us to…

CalVer

Calendar Versioning is, ironically, more semantic than SemVer. The version number is the date when the software was released. For example, Ubuntu releases are in the form of YY.MM - the latest stable release at the time of writing is 24.04 - so we can tell that it was released in April 2024.

There are three main problems with this approach.

1. ISO8601 or GTFO! Surely these should use YYYY-MM to make it obvious this is a date?
2. Minor bug fixes are often given a release number like 24.04.1 - is that still obvious it is date-based? Was it really released on the 1st of April?
3. No information about big and/or breaking changes. Software released several years apart may be functionally identical whereas software released days apart may be incompatible.

Alternatives

So, what other ways can we number software versions?

EffVer

Effort Versioning is, I think, a sensible way to standardise SemVer. It attempts to show how much effort it takes to move between versions.

PrideVer

How much Pride do you have in your software release?

This is SemVer for people with an ego and the coding chops to match.

RuffVer

Ruff is a sort of bastard child between SemVer and CalVer, but adds this delightful complication:

Stable releases use even numbers in minor version component: 2024.30.0, 2024.32.0, 2024.34.0, … Preview releases use odd numbers in minor version component: 2024.31.0, 2024.33.0, 2024.35.0, …

It's the versioning equivalent of setting up a fully scalable cloud database and hand-chiselling HTML out of stone for the cookery blog you update twice per year.

0Ver

Zero-based Versioning tells us that it is forbidden to ask and a sin to know when a piece of software will be completed.

Essentially, it is SemVer for cowards who are afraid to commit. The opposite of PrideVer.

PiVer

The venerable TeX uses Pi Versioning. The current version is 3.141592653, the next version will be 3.1415926535.

As the software gets refined, it gradually reaches a state of perfection. This is a charming versioning scheme which shouldn't be used by anyone other than Knuth lest hubris overtake you!

NameVer

Sometimes marketing takes the reins and insists that consumers need a Named Version to help prevent confusion.

Ubuntu uses things like Bionic Beaver, Distinct Dropbear, and Mantic Minotaur. By convention, names increase alphabetically, so you should know that Jaundiced Jackdaw is before Killer Kangaroo - until you've released 26 version and have to wrap around the alphabet again.

NameVer is helpful for distinct products which aren't related, but probably more confusing than necessary.

WinVer

Microsoft Windows uses this very logical scheme - 1, 2, 3, 3.11, 98, 2000, Me, XP, Vista, 7, 8, 10, 11.

It starts with more-or-less SemVer, then jumps to CalVer, then 4 digit CalVer, then to NameVer, then back to SemVer - skipping 9 because of alleged technical reasons.

Do not attempt to use this versioning unless you want to anger both gods and mortals.

KelVer

Absolute Zero is defined as 0K. And so, Kelvin Versioning counts down to stability.

Almost the opposite of PiVer - the closer this gets to zero, the closer the code is to being complete.

This versioning scheme is affront to most sane people. But here's to the crazy ones.

Non-Monotonic

You will notice that all of the above are monotonic. That is, they all proceed in one direction and never reverse. Any subsequent version was definitely released later than a previous version. So, in a sense, they all contain some level of semantics.

But they don't have to.

HashVer

Taking the Cryptographic Hash of the code, or a commit, allows one to create Hash Versioning. For example 43317b7 is a HashVer for something which would otherwise have the dull and unworthy name of v0.118.1

But, of course, a hash does have a modicum of semantic information - even if it is only loosely related to the content of the code. What if there were something with no semantics and no monotonic behaviour!?!?

RandVer

Embrace the weird with Random Versioning! It its heart, RandVer says pick any number that hasn't been used before.

Perhaps V7 is followed by V2.5, which is overtaken by V0xDEADBEEF

Absolutely guaranteed to have zero semantic content.

What have we learned today?

The square-root of bugger-all.

Over the last 20 years, open source software has undergone a significant shift—from providing an optimistic model for public collaboration to undergoing constant maintenance by the often unseen solo operators who write and publish the code that millions of users rely on every day. In Working in Public, Nadia Eghbal takes an inside look at modern open source software development, its evolution over the last two decades, and its ramifications for an internet reorienting itself around individual creators. By delineating the structure of open source projects, she explores, for the first time, the maintenance costs of production that software incurs for its developers. Drawing on hundreds of developer interviews and analyses of platforms like Twitter, Facebook, Instagram, Twitch, and YouTube, Eghbal argues that examining who produces things on the internet, and not just what they produce, helps us understand the value of online content today.

This is an excellent book. If you're an experienced open source developer, it'll bring clarity to a bunch of concepts you're familiar with but couldn't name. If you're managing teams who work with - or produce - open source, it'll give you a greater understanding of the scene and its limitations.

Given the current furore with Log4J developers basically being volunteers, the book presents several ways that critical open source can be funded.

But, for me, the best thing about it is the way that it reflects our culture at this moment in time. Sure, it covers the history of F/OSS and it looks to the future - but it is mostly about what working on Open Source is like right now.

If you're interested in software as a cultural movement - and its intersection with commerce and government - this is the book for you.

Similarly, the food industry has "prêt-à-manger" - ready to eat. No telling l'artiste du pain how much mayo you want, just grab a boxed sandwich and start munching.

What's the equivalent for Open Source Software?

(I know it is facile to say "There are two types of X in the world..." but I'm going to do so anyway.)

There are two types of Open Source Software in the world, those that "just work" and those that make you want to bash your head against your monitor and go live in the woods without electricity.

In my infinite wisdom, the best sort of OSS requires no installation, no esoteric configuration, no mystic incantations, no downloading dependencies. A simple ./whatever and you're off to the races.

I loathe stuff where the running instructions say "Install these seven external programs (half of which require compiling, the other half haven't been updated in a decade), fill in this tedious YAML document with a billion options, download yet another version of Docker for no particular reason, oh and remember to set --safe-mode=true when you run or it'll delete all your files."

GAH!

I appreciate that some software is complex. And not everything is amenable to a flatpak or snap package. And a developer's time is finite. And you get what you pay for. And that sometimes it is simply better to have a steep learning curve.

But most times I just want to download and run.

So, on to the most important matter of this thesis. What should we call this sort of software? I conducted a highly scientific Twitter survey - and these are some of my favourite answers:

Pret-a-Docker? (oh god)

Ben Nuttall

@ben_nuttall

Replying to @edent@edent Pret-a-Mongo

---

prêt-à-monger?

angusprune@mastodon.lol 🫡

@angusprune

Replying to @marxculture@marxculture @edent Prêt-à-god-it-works

---

Dan "Quietly Quit" Hon

@hondanhon

Replying to @marxculture@marxculture @edent Prêt-allo-monde

---

Russell Howe

@rhowe212

Replying to @edent@edent Wget-a-bash

---

Adrian Tchaikovsky

@aptshadow

Replying to @edent@edent Pret a ecran bleu de la mort.

---

prêt-à-bugger

Ben Thorp

@benthorp

Replying to @sil@sil @edent OSS that requires no installation *or* esoteric configuration? pret-er-miracle.... ;)

---

Prêt-à-plug-'n'-play

Ben Nuttall

@ben_nuttall

Replying to @edent@edent Actually it's GNU/Pret

---

chrisbeeley@fosstodon.org

@ChrisBeeley

Replying to @edent@edent I don't know but this reminded me of this excellent tweet

x.com/leahvelleman/s…

So I guess my answer would be

Pret a piano pas

(sorry my GCSE French is letting me down a bit here)

---

Bruce Lawson

@brucel

Replying to @edent@edent "What phrase would you use for stuff which requires no installation or esoteric configuration?"

"A web site"

---

Lots of Open Source licences give the consumer of software the right to a copy of the source code.

For example, GPLv3 says that distributors of software have to:

give anyone who possesses the object code ... a copy of the Corresponding Source

What is "Corresponding Source"?

The "Corresponding Source" means all the source code needed to generate, install, and run the object code

That, to me, reads like a user is only entitled to a code snap-shot. Not the full history of code development, but just the version of the source used to compile the distributed binaries.

My question to you, gentle reader - are there any licences which compel the distribution or publication of the development history?

Is this a good idea?

Services like GitHub and GitLab now dominate the open source conversation. But nothing about FOSS says that you must develop in public. It just seems to be the social norm now.

But I don't see any reason to make it a compulsory part of a licence.

I have a Linux laptop with built in speakers and an external monitor with speakers. The laptop connects to the screen via HDMI. I have my Linux desktop set up for dual screens.

If I drag a window from one screen to the other, I want the sound to follow the window.

Is this possible?

A bit more detail

When I have YouTube running on my monitor, I want the sound to come from the monitor.

When I have a video conference running on my laptop screen, I want the sound to come from the laptop's speakers.

POP!_OS running Wayland gives me the option to set the default audio output.

Some apps - mostly video conference apps - let me select the audio output of that app. So I can set the output to my headphones or screen or laptop or Bluetooth speakers or the misconfigured Smart TV next door.

Is this actually what I want?

My laptop usually has a wired headset and a Bluetooth headset connected - along with the built in speakers. What I really want is for my webcam to notice what headset I'm wearing and route audio to that. If I'm not wearing headphones, notice which screen I'm looking at and route audio that way. Except when I'm playing music on one screen and working on a document on a different screen.

Butler. I want a human butler to surreptitiously readjust the sound output based on my subconscious whims.

But it's a term that I think we're going to be hearing a lot of in the future.

Jake Levine recently wrote an excellent post on apps which don't require any interaction. It's not quite as crazy as it sounds - the interfaceless application - but refers to a class of program where the only interaction is in the act of being notified.

The examples given are fairly obvious in retrospect - an app whose only function is to play a sound when it's about to rain, an exercise app which notifies you once per day about how many calories you've used.

We see these a lot with SMS alerts - e.g. a notification to say your credit card has been used. Automated emails from services which tell us what our website stats are for the month.

There is a risk that we get overwhelmed by these notifications. Not just through Fear Of Missing Out - but just through the sheer volume. I'm sure we've all gone through periods of unsubscribing from every bloody newsletter which has flooded our inbox.

That's a fairly visible nightmare. It's what happens next which scares me.

Invisible Apps

Are there apps which you use, silently making changes, and you're not even aware of them? Of course!

On a prosaic level, there's the app which automatically adjusts your screen's brightness. The app monitors the ambient light and silently adjusts the screen so it is readable. It never pops up and says "Hey! I just changed the screen - keep this brightness? Y/N" It just plods along.

We are surrounded by devices passively collecting information, and then making autonomous decisions.

Can we ever know why those decisions are made? Can we understand and - more importantly - correct their mistakes?

Google Now scans my inbox and occasionally alerts me when it thinks I'm about to miss a flight. Handy - but creepy. It would be trivial for it to see my calendar for tomorrow, see that there's bad traffic, and autonomously decide to set my alarm clock app to wake me half-an-hour earlier than usual.

That's... good. Probably. In an ideal world where Google Now is 100% confident that I'm not taking the bus, or had decided to cancel, or any one of a hundred other variables that may impact the decision making process.

Your phone could look at your temperature, your hormone levels, shopping habits and correctly conclude you're pregnant. Is it acceptable if your phone refuses to let you order a glass of wine? What if it automatically tells your friends to cancel your joint sky-diving lesson?

As we move more of our life into digital services, it's temping to think of our phone as a latter day butler. A silent presence, looking over our shoulder, getting us out of scrapes and - somehow - always knowing when to call us a taxi home.

It's possible that the level of artificial intelligence needed to do this in a useful way may arise - I'm not confident of seeing that any time soon. Having a butler that is continuously intervening - and is often wrong about its interventions - would be supremely distressing.

A Malicious Siri

Do we need protecting from autonomous robots making important decisions for us?

Take, for example, your credit score. There are thousands of software processes which are automatically looking at your spending, your saving, how quickly you pay back debt, and a hundred other facets of your life. All of which builds up to create a credit score - essentially a quantified risk profile. If your score is too low - no mortgage for you.

What are the systems which decide these scores? Are they accurate? Do they have bugs? Are they the same systems which gave a clean bill of health to Lehman Brothers?

Imagine your phone realises that it's in a noisy environment - so switches from silent mode to loud mode. Useful, unless you're in a cinema and receive a call during the emotional dénouement.

Worse, could our "faithful companions" be actively working against us?

Imagine Amazon released "Percy The Personal Shopper". A smart software agent which would do your shopping for you - picking out the latest fashions in the correct sizes, recommending books you'll just love! What could be better? (Assuming he is smart enough to understand your sarcasm and doesn't automatically order you 3 tons of potatoes.)

But, of course, Percy doesn't work for you. He works for Amazon. He isn't suggesting clothes you'll like - he's suggesting clothes which are taking up space in Amazon's warehouse, or perhaps those which have a high profit margin.

Your exercise scheduler (Free! Sponsored by Nike!) automatically arranges tennis matches for you against better players who just happen to have a Nike racket.

Your calendar automatically sends your grandmother flowers on her birthday. It doesn't know she died and you just keep the reminder in your calendar as a memento.

Taking Control

Automatic decision making is a fascinating branch of artificial intelligence. It won't be long before Google Now and Siri really do start taking actions for us in the background rather than simply notifying us.

How do we stop these invisible systems from tormenting us with their ill-informed - but well intended - actions?

Essentially, OBD (On Board Diagnostics) is a port which is found on every car produced since the late 1990s. It allows garages to see all sorts of diagnostic information about your car, its engine, and all other manner of petrol-headed goodness. It's designed to be easily accessible and conform to a common standard.

So, it's no surprise that a whole cottage-industry has developed around this port. Whereas connecting to OBD used to be something done only by garages, now anyone can buy an adapter. Which is how I got this £20 BlueTooth capable OBD dongle.

After scrabbling around in my new Toyota Yaris Hybrid, I found the OBD port just to the right of the steering wheel.

Fitting it was simply a matter of figuring our which way round it went, and then jamming it in. It fits well and doesn't feel like it will fall out - but a bit of gaffer tape may be in order to secure it when I drive along bumpy roads. As soon as it plugged in, the lights started flashing and I was able to pair it with my Android phone.

Security

The default code for these things is either "0000", "1234", or "6789". I really wish that could be changed. OR, at least, print a unique 8 digit code on each device. Essentially, the unit is on all the time - slowing drawing energy from the battery - which means that it is discoverable all the time.

So, anyone walking around the car park - or stuck in traffic with me - can get a full readout of my car's diagnostics.

True, it's not the biggest security threat in the world. We know that proprietary software is riddled with bugs. Toyota had to recall hundreds of thousands of cars due to software glitches.

Perhaps there's a bug in the car - or the device - which will let an attacker stall the engine, or unlock the doors, or find out my fuel efficiency.

Of course, I could unplug the dongle every time I get out of the car (some units have physical power buttons) but that's a faff I can do without.

The Plan

I'm using the free Android app Torque (Pro Version available for £3).

It's a nifty program which lets you monitor (and export) data from the engine. My phone will quite happily pair with the car's audio system and the OBD dongle - so that shouldn't be a problem. But it does rely on my remembering to pair the device (and take my phone with me!).

What I'm planning to do is use a cheap 2nd hand Android phone to act as a 3G bridge for the dongle. The Yaris has a USB port hidden in the glove compartment - it's usually used for playing music from a USB stick, but I think it should be sufficient to trickle charge a phone.

As the car doesn't have a built in GPS unit, I can use the Android's GPS to keep track of the car. I can use its 3G connection to email or text me whenever the car is moved - useful if it's being stolen or towed. I can plot my journeys, automatically let my wife know when I'm stuck in traffic, and all sorts of other jiggery-pokery.

Let the hacking commence :-)