Reflections on NDC London and PubConf

NDC London was the first really big conference I ever went to - as a paying attendee, way back in 2014 (or was it 2013?), when I was trying to figure out ASP.NET MVC and jQuery and how to get all my team’s code out of Subversion and into this new Git thing everybody was talking about.

I love it. I love welcoming everybody to my home city, I love the atmosphere, I love the location. It’s also where we held the very first PubConf, an event that celebrates just how incredibly funny a lot of conference speakers are - especially when the drinks are free and everybody promises not to post clips on the internet; there is something genuinely delightful about watching a speaker spend an hour artfully deconstructing distributed systems architecture or unit testing strategies in front of a conference audience, and then the next night they’re on a tiny stage in a crowded pub making you laugh until the milk comes out of your nose.

I’ve been at NDC London every year since, wearing all kinds of hats both metaphorical and literal, and become the de facto organiser of PubConf London since Todd Gardner cut down on conference travel a few years ago to focus on growing TrackJS and Request Metrics. With NDC London and PubConf successfully signed, sealed and delivered for another year, here’s a bit of a reflection on it.

Now please bear in mind, this is my experience - not yours. Unless you are also (a) living in London, (b) teaching a conference workshop, (c) giving a talk, (d) running the attendee party, (e) organising the unofficial after-party on Friday night, (f) playing lead guitar and singing in the band that will be performing at that party, (g) mixing the backing tracks and videos that band is going to use on stage, (h) running the website that handles all the event ticketing and registrations, and (i) flying to Stockholm 72 hours later for another conference, this is not how NDC London was, is, or ever will be for you.

Think of this more as a glimpse into how Dylan’s link of the proverbial sausage gets made. (I shall leave it as an exercise for the reader to decide whether the story is told from the perspective of the butcher, or the perspective of the pig…)

The thing that makes NDC London different to most other events in my calendar is that it’s a hometown show. I live in London; it’s been home for nearly 25 years. But London isn’t like other places. Not even close. I live about 6 miles away from the QEII conference centre, as the crow flies (although this being London the crow is probably a feral pigeon) - but 6 miles in London is not like 6 miles where you live. The easiest way to explain it is that I probably pass two million people on my way in to Westminster every morning. Think about wherever you live. Draw a line from your house to whatever your nearest analog for “city centre” looks like… now keep going along that line until you’ve gone past two million people. See?

A typical conference week for me is half a day of packing - what do I need this time? If I’m running a workshop, I have a bunch of gear I use for that - portable HD screen, HDMI splitter, external keyboard. If I’m playing music at the after-party, I bring one set of music gear. If I’m doing a show with The Linebreakers, it’s a different set of music gear. Laptop, spare laptop, cables, chargers, clothes, wash bag, passport, pack all the things, head to the airport - and that’s it. The logistics are all front-loaded; once that bag’s been checked in and I’m through security, we’re done; the rest of the week is hotel breakfast, catered lunches, restaurant dinners, housekeeping bringing fresh towels… the actual event itself is often hard work, ‘cos that’s what makes it worthwhile, but the rest runs on autopilot.

When it’s a hometown show, things run a little different. Tuesday is a workshop day, which means up at 6am, coffee, porridge - always porridge on workshop days ‘cos it keeps my brain running until lunchtime - and then on a train by 7:15, which gets me to Westminster by 8, which is an hour early, but if I leave it any later than that there’s a good chance the Jubilee line trains are all too full to get on. Twenty minutes to set up the laptop, screen, HDMI splitter, keyboard, check the WiFi, find out which websites are being blocked, figure out how to work around them. Workshop 9am-5pm - live coding exercises, demos, examples, Q&A. Wrap up, deal with the day’s admin and reply to emails, then another hour on trains to get home. Unpack, figure out what I need to take in with me on Wednesday, make dinner, do the laundry, sleep. The Linebreakers are playing PubConf on Friday night, so my plan is to take a case full of band gear into the conference venue each day - as much as I can comfortably carry on public transport - then on Friday shift the whole lot to the PubConf venue in a cab. Wednesday’s an electric guitar and 10kg of effects and cables shoved in my rucksack. Thursday, a 15kg flight case full of microphones and XLR cables. Friday, 25kg wheely case with the mic stands, second guitar, laptop stand, and all the other bits that make the show happen.

My actual talk is on Wednesday morning - and it’s a new one, so I’ve been up late the night before finessing animations and checking videos. New talks normally get run through a user group a month or so before the conference… but with NDC London always happening at the end of January, Christmas tends to get in the way a bit and there’s not a whole lot of meetups going on in the weeks leading up to it. The talk goes well, although the room’s a little emptier than I expected; maybe it’s just the general dip in conference numbers, maybe it’s just that people don’t want to learn about CSS? But I’m happy with it, and the folks in the room said very positive things.

Wednesday afternoon is band rehearsal - the downside of having a band who all live in different countries is that we don’t get a whole lot of rehearsal time, so this is where weeks of everybody learning their own parts and playing along to backing tracks finally gels into something approximating a show. It goes well. I skip the speaker dinner in favour of sleep. Sleep is good.

Thursday I have every intention of going to some talks. It doesn’t happen - the day disappears into a series of the sort of excellent conversations that only happen when the right people are all in the same room, catching up with folks from Particular, and Dometrain, and Twilio, and Umbraco, and old friends from the nerd circuit who I haven’t seen in way too long.

Thursday evening I’m running the NDC party. Now, I think the social events at conferences are just as much a part of the attendee experience as the talks, but the speakers who do the fun talks and comedy bits at the party? Most of them aren’t giving it the slightest thought until their “proper” session is out of the way - which is absolutely fair enough. This means the party inevitably coalesces out of chaos at about 3pm on Thursday - but you know, after more than a decade of doing this, we are damn good at coalescing things out of chaos. The party itself is a blast - Alan Smith’s Sonic Pi DJ set is fantastic, there are great comedy bits from Glenn Henriksen, Hannes Lowette, Amy Kapernick, Ash Bzak, Richard Campbell tells the story of Goliath, which I have seen half-a-dozen times and still makes me roar with laughter every time. I dust off my old “How To Succeed in the Enterprise” talk I wrote for PubConf a few years back, which goes down a storm, and we round out with karaoke, which works great in this kind of venue ‘cos you’ve already got a laptop, a huge projector screen, and a couple of handheld mics so there’s nothing much to pack up at the end of the night.

Home just after midnight (and stone cold sober, because Friday is another day). Dinner was Mexican food at the party (did I mention the food at NDC is always excellent?) but that was a long time ago, so second dinner is a chicken baguette from Greggs in Westminster station, which happens to be open and adjacent at the exact moment I realise I’m starving. Just in case any of you were reading this thinking that the international conference circuit was 100% glitz and glamour.

Friday morning, I take an hour out of conference time to get out on my bike; cycling the five-mile loop to the top of Crystal Palace Park every day this winter has been doing good things for my blood pressure and my brain - not to mention my knees - and as loath as I am to admit it, I actually miss the exercise after three days of conference. This is, of course, the day that I get a puncture right at the top of the hill. I figure it’ll be quicker to fix it and cycle than to wheel my bike all the way home, so I spend fifteen minutes in the cold changing the tyre; cycle home, shower, get dressed, grab my backpack and the 25kg wheely case and head into Westminster again.

Friday lunchtime is about the point when the folks speaking at PubConf finally start sending me their presentations, so on Friday afternoon all I need to do is transport 50kg of music gear to the pub, schlep it downstairs, figure out their PA system and projector set-up, plug it all in - which would be enough of a pain in the ass if it was on a bench in a well-lit workshop; doing it on the floor in a dimly-lit pub is definitely my least favourite part of the whole enterprise - while simultaneously building the PubConf deck as people send me Dropbox and OneDrive links to MP4 and PPTX files.

There’s always a list of things we think would be cool - let’s record the show! Let’s get video of the show! - that, by the time we’re set up and sound-checked, we’re already too knackered to think about… and then the audience starts to arrive, and the excitement starts to build, and the room fills up, and there’s a buzz, and I get the last few bits dropped into the presentation deck, and then… showtime.

With, inevitably, a handful of technical glitches. PowerPoint on macOS decides today’s the day it’s going to play Chris Ayers’ MP4 at three frames per second. It has never done this before. Ever. Sorry, Chris. Computer says meh. A reboot seems to clear it. The XVive wireless monitors that we use in the band, which worked flawlessly during soundcheck (and at every show we’ve done before) - tonight, channel 1 isn’t working. It worked earlier… maybe interference from 75 nerds with at least one WiFi-enabled device each packed into a basement that’s basically a giant Faraday cage? Channel 2 isn’t great either, but hey, we’ve got four more to try… cue some hastily improvised jokes about the history of UK broadcast television and how we don’t want to try Channel 5 in case it all comes out sounding like the Spice Girls - while we’re simultaneously channel-hopping our wireless units to find a channel that works; channel 3 saves the day. In the logistical chaos, I forgot one tiny bit of gear - the thing that clips my phone onto my mic stand, so I can adjust my own in-ear monitor mix during the show. Probably no big deal… right up until the point I realise during “Playing the Planning Poker” that I can’t hear the drum track, and I can’t fix it right away ‘cos it’s hard to get your phone out your pocket when both hands are busy playing the guitar… I make a mental note that it is, in fact, a Big Deal and I probably shouldn’t forget it again.

But the show is a triumph. The PubConf speakers - Chris Ayers, Brandon Minnick, Glenn Henriksen, Chris Simon - and the PubConf singers (yep, that’s a thing now) - Ash Bzak, Helvira Goma, Jo Minney, Damian Brady, David Whitney, William Brander, Jordan Miller, and Arthur Doler - absolutely smash it out of the park; the band plays a couple of new things we’ve not played in London before that go down really well, Rytis does a fantastic job running the sound mix on the venue’s slightly temperamental PA system, and Vagif gets the biggest applause of the night after dropping out of the gig because of a broken shoulder but then deciding to come along and play a couple of tunes anyway.

There’s a surprise, too… as we’re about to launch into “Enterprise Waterfall”, Hannes stops the show, Chris Ayers approaches the stage with a VERY LARGE BOX, and the gang presents me with the Lego Starship Enterprise - a little something to say thank you for Making The Crazy Things Happen. I’m lost for words. I actually cry a little. It’s perfect. It’s lovely. It’s completely unexpected. (It’s also another 6kg of luggage to take home at the end of the night… but hey, at this point, who’s counting? 🤣)

And then there’s music, and dancing, and laughter, and karaoke, and rye whisky, and single malt scotch and a very expensive cab home, and more scotch, and something approximating sleep, and then a day of bad TV and tactical naps and Chinese food and working on promo materials for the next thing I’m doing, and then a day of unpacking and repacking (and another puncture), and now, less than 72 hours after it all wrapped up, I’m on an aeroplane somewhere over the North Sea on my way to Stockholm, where there’s four inches of snow on the ground, a load of Java developers at one conference, and a load of .NET developers at another conference. The plan is two talks, two dinners, one live music and comedy show, say hello to as many people as I possibly can, give the stone lions a hug, pay my respects to Pub Anchor if I can find the time, and be home in time for the open mic at Ignition on Thursday night.

Should be fun.

The Road to Excel

Chris Rea’s “The Road to Hell” is one of my favourite albums of all time. You probably remember the title track, but the rest of the album is fantastic - great tunes, great production, and some truly phenomenal guitar playing; Chris had a very distinctive hybrid slide playing style, something between Mark Knopfler and Ry Cooder, and it’s all over this record.

Now, back in 2021, when the news headlines was full of reports that COVID patient data was getting lost because of government departments using Excel as a data interchange format, I recorded a version of Chris Rea’s “The Road to Hell” about… well, about exactly that.

I never got the guitars quite right - did I mention that Chris was a phenomenally talented guitar player? After a week or two of of trying to figure out the guitar lines, recording and re-recording licks and solos and never quite getting it all to hang together quite right, I shelved it and it’s been sat in a Dropbox folder ever since.

With the sad news of Chris’ passing this week, I thought perhaps now would be a good time to share it. Not finished, no video, you can hear the rough edges - but here it is.

Rest in peace, Chris. Thank you for the music.

So You Want To Speak At Software Conferences?

I run a .NET user group here in London, and we host a lot of talks from people who are relatively inexperienced presenters. Sometimes they’ve done presentations internally but never spoken before a public audience. Sometimes they’re developers who have been in theatre or played in bands; people with plenty of stage experience but who haven’t presented on technical topics before - and sometimes they’ve never done any kind of public presentations or performance at all. We aim to be a friendly, supportive crowd; public speaking can be daunting, and the first public outing of somebody’s first talk can be… let’s just say that the presenter sometimes learns a lot more than the audience, and leave it at that.

But it can also be a hugely rewarding experience, and as a seasoned tech presenter who’s been doing this for a while, aspiring speakers often ask me for advice on how to take it to the next level.

Before we get into the specifics, there are two things to bear in mind.

One: ask yourself why you want to do this. What does “the next level” mean for you? Are you looking to promote your consultancy, or your training courses, or your software products? Do you want to become a professional speaker and actually get paid to give talks? Are you doing it ‘cos you want to go places and meet people? Figure out what “success” looks like for you.

Two: be realistic about how much work is involved. It took me seven years to go from my first user group lightning talk, back 2008, to my first international conference. If you think you can hack together some code, write a talk about it, stick it on Sessionize and three months later you’re on your way to a major international event like NDC or Yow! or Devoxx… well, no. That’s not how this works. Strap in; it’s a long ride.

Year 1: Get Good

Write the talk. Write a talk nobody else could do; tell a story nobody else can tell. Figure out what your audience is going to learn, and why you’re the best person to teach them that. Then give it at local user group. It might go great. It might be a train wreck. Don’t worry. That’s one of the reasons user groups exist. Learn from the experience. Fix the demos. Fix the slides. If it was too short? Write some more. If it was too long? Cut something. Give it at another user group. Do it again. Do it again. Maybe write a second talk, shop that one around a couple of user groups too.

If you can’t find user groups, look on Meetup.com. Yes, it’s a horrible platform, but it works; search by topic, search by region, find groups that look like a good match for your content, and ask if they’re looking for speakers. They probably are.

Year 2: Get Seen

After user groups and meetups come the community conferences. Typically small, one-day events, with a few tracks, and usually free (or very cheap) to attend. For me, these were the DDD events _(that’s DDD as in Developers! Developers! Developers!, not to be confused with DDD as in Domain Driven Design), _a series of one-day free developer events around the UK, organised by volunteers, usually on a Saturday so people don’t have to take time off work. They bring in a good crowd, they’re a great way to get to know other presenters and people who are involved in tech events, and you’ll almost certainly meet a few people who are on the programme committees for the bigger conferences.

Events like this are your chance to get noticed. Turn up the day before, join the pre-conference dinner and drinks, introduce yourself. Yeah, it’s awkward when you don’t know anybody. There will be other people there who don’t know anybody and will appreciate you making the effort. Enjoy yourself, but don’t end up doing tequila shots in a karaoke bar at 3am. Not now. You’re there to give a talk, remember?

Go to the event. Spend the whole day there, do your talk, watch the other sessions. Communicate with the organisers. You don’t want their memorable impression of you to be a half-hour of panic and missed calls because one of their speakers has gone AWOL and nobody knows where they are.

Figure out how to keep in touch with the people you met. Join the Signal or WhatsApp group chat; if there isn’t one, create one. Follow them on LinkedIn, or Bluesky - be prepared to go where people are; don’t expect folks to join Mastodon just because that’s where you want to talk to them. That’s not how this works. If you really don’t want to play the social media game - and I can’t blame you - there’s always good old-fashioned email. A short email a week later saying “hey, thanks for having me” or “hey, I loved your session at DDD, let’s keep in touch” can pay off in a big way.

Finally, watch out for events that put video of their sessions online. Having a couple of YouTube links of you doing your thing in front of a live, appreciate audience can make all the difference when a programme committee is looking at a handful of talks and can only accept one of them.

Year 3: Get Accepted

You’ve got a couple of talks. You’ve delivered then enough times that you know they’re good *(and if they’re not good, make them good - or scrap them and write new ones)*. You know people. People know you. If somebody asks “hey, do we know anybody who could do a good session about $topic”, your name comes up. You’ve got a decent network of connections - group chats, LinkedIn, email addresses.

Now, find all the conferences in your field with an open Call for Papers (CfP), and get submitting. Dave Aronson over at codeasaur.us maintains a really useful list of CfPs which are closing soon. Check that regularly. Many events will cover your travel & hotel costs, although with sponsorship budgets drying up right across the industry that’s not as prevalent as it was a few years ago. If not, maybe you can persuade your employer to pay your travel - “hey, boss, if I can get a free ticket to this amazing conference with all these industry experts, do you think the company will pay my air fare & hotel?”

Lean on your network. What are people submitting to? Which events should you look out for? Which topics are getting a lot of traction (and which topics are not?)

Keep your content fresh. Write new talks. Keep giving them at user groups and community events.

Keep your submissions focused. 2-3 talks per event; don’t submit ten wildly different abstracts to the same conference in the hope one of them will get accepted. Every selection committee I’ve been on, if we see that, we assume the presenter hasn’t actually written *any* of them yet and is throwing everything they can think of into the mix and hoping one of them gets chosen. Not a great way to stand out. An open CFP at a big tech conference typically gets 20+ submissions for every available slot, which means if you reduce it to a numbers game, you’re submitting 20 talks for every one that gets accepted. Keep track of the numbers, and be objective about it.

Year 4: Get Bored.

It’s great fun doing this for a while… but it’s also exhausting. Some people hit it hard for a few years, do all the things, go to all the places, make a lot of great friends and happy memories, and then wake up one day and decide that’s enough. Some people do a few talks, tick it off their bucket list and decide that’s enough for them. Some settle into a gentle routine of 3-4 events they’ll do every year. And yes, some of us end up treating our calendars like a game of Tetris, juggling flights and trains and hotels and meetups and conferences and spending half the year on the road and the other half writing talks and workshops and all the other things it’s hard to do when you’re at the airport.

That’s why you gotta figure out ahead of time what “success” looks like. If you’re doing it for fun, remember to have fun - and if you find you’re not enjoying it any more? Stop. If you’re doing it as promotion or marketing? Track your leads. Make sure it’s actually generating the attention and the revenue it’s supposed to. If you’re doing it for money, be mercenary: no pay, no play. Not every event is the same, of course. In a given year I’ll have some events that are fun, some that are lucrative, some that are running alongside workshops or training engagements. Just make sure you know which is which.

Finally: respect your audience. Whether you’re talking to five people at a meetup, fifty at a community event, or five thousand at a huge international conference: those people are the reason you get to do this. They have given up their time - and often a substantial amount of money - to hear what you have to say. They deserve your best shot, every time. If you find you’re bored, fed up, tired, running talks on autopilot or making mistakes because you just don’t care? It’s time to try something else - and remember, there’s a thousand aspiring speakers out there who would dearly love to take that spot instead of you.

Now get out there. Work hard, have fun, teach us awesome things, and if you ever want me to look over an abstract or a slide deck, drop me a line - [email protected]. I’d be happy to help.

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.