Reflecting on 10 years of the OpenBLT bootloader

The 12th of November 2021 marked a special day for the OpenBLT bootloader: Its 10-year anniversary. A great opportunity to take a moment and reflect on its history and ponder the question of how it became such a success.

Version 0.90.0 was the first ever open source version of the OpenBLT bootloader. I published it on SourceForge on the 12th of November 2011. You can still download it:

Partial web browser screenshot of where you can download the first public release of the OpenBLT (version 0.90.0) from SourceForge.

Only 1 MB in size and it supported just one microcontroller family, the NXP LPC2000 series based on an ARM7 core. In contrast, the current stable release (version 1.12.1) is 137 MB in size and supports nineteen different microcontroller families. The majority of them Cortex-M core based, simply because that is what most of us are using nowadays.

The 2016 turning point

Being self-employed since 2003, when I founded Feaser, I was mostly doing embedded contracting and consulting work for clients. The OpenBLT bootloader was a hobby project I did in my spare time. I didn’t expect much to come out of it. However, slowly but steadily more and more companies contracted me to do OpenBLT bootloader portation and customization work for them. To the point that in 2016, about half of my income was generated by these OpenBLT bootloader projects.

I started dreaming: Wouldn’t it be great if I can dedicate myself and Feaser 100% to the OpenBLT bootloader? It would result in a better bootloader, with more features and supporting and ever growing number of microcontroller families. The only way forward was to somehow increase the income generation, to make working on it full-time a viable option. Just trying to sustain yourself from support, portation and customization work wasn’t going to cut it. I saw only two possible options:

  1. Find a large company willing to sponsor the OpenBLT project.
  2. Switch to a dual licensing model.

My preference went to option two, because that way I kept more control over the project and frankly, I didn’t know of any large company willing to sponsor the OpenBLT project at that tme.

Introducing the dual licensing model

Up until that time (mid-2016), OpenBLT was based on the GPL v3 license, with a special exception. The exception allowed you to create a combined work without having to open source your own code. Similar to what FreeRTOS used in the beginning, before the Amazon time. Essentially allowing you to use it for free in proprietary closed source embedded applications.

When switching to the dual licensing model, I removed this exception from the license. So OpenBLT is now released under a true GPL v3 license with all its copy-left benefits, but also requirements. Integrating GPL v3 source code into a proprietary closed source product is a no-go. Since the entire OpenBLT bootloader was completely developed by just me, my company Feaser holds its copyrights. This makes it possible to release the same software under a commercial license as well. So stripping out the GPL v3 license and replacing it with a commercial license. This makes OpenBLT suitable for integration in a proprietary closed source product:

Comparison table of the GPL v3 and the commercial license, further clarifying the dual licensing module of the OpenBLT bootloader, which attributes to its success.

Five years later, I can conclude that the switch to the dual licensing model was pivotal. Hundreds of commercial licenses were sold, realizing my dream and allowing me to work full-time on the OpenBLT bootloader. The dual licensing model established a well-balanced synergy between my company Feaser on the one side and the open source OpenBLT project on the other side.

In hindsight, I believe that such a dual licensing model is the only feasible option to make an embedded open source project sustainable. Otherwise it will just be something you do on the side. Never reaching its full potential. Chances are you’ll even loose interest over time, slowly causing users to lose interest and the project just being a bunch of code collecting dust.

Contributing success factors of the OpenBLT bootloader

The dual licensing model was needed to turn the OpenBLT bootloader project into something sustainable. But that only works if the product itself is good. In this section I’ll dive a bit deeper into what led to the success of the OpenBLT bootloader and what sets it apart from the competition.

Trend towards more embedded open source

In my opinion, the foundation of the OpenBLT bootloader’s success is the fact that it is first and foremost and open source solution. With the rising firmware complexity and features, companies look for a way to shorten the time-to-market and lower cost at the same time. Embedded open source fits right in there.

Combined with the dual licensing model, it’s the ultimate try-before-you-buy solution. With the OpenBLT bootloader’s publicly available code, developers can integrate it into their product right away for evaluation purposes. And if it works and meets their requirements, why bother wasting precious engineering resources by trying another solution?

Well commented and documented code base

A software product is only as good as its documentation, especially if the software is meant to be used by others. Luckily, I enjoy writing. In fact, I do much more writing than actual coding these days. I take pride in making sure that everything is properly commented in the code. Users seem to appreciate this as well, based on the feedback I get. Here’s just one of the many testimonials:

It’s been an absolute joy looking through the OpenBLT source code. It’s legitimately the most thoroughly commented code I’ve seen in my life. Everything is so organized and explained, and it’s super easy to follow along. Great work, man, seriously. I wish everone’s code looked like yours.

It goes further then just commenting the source code. There’s the Wiki with more detailed background information, including an FAQ section. And don’t forget the developer blog that you are currently reading this article on.

Publishing documentation about the OpenBLT bootloader online, helps with search engine optimization as well. If you search for “open source bootloader”, the OpenBLT bootloader currently pops up as the first result in Google:

Screenshot of searching for "open source bootloader" in Google, that illustrates that the OpenBLT bootloader is the first search result.

Overcome the challenges of integrating third party code

The lifetime of an embedded system is long. Typically over a decade. This brings along several challenges, when deciding on integrating third party code into your own product. To name a few:

  • Will the code still be maintained in the future?
  • Who monitors the quality of the code?
  • Is someone available for technical support?
  • How and when to upgrade to a newer version?

This applies to all third party code, but especially to embedded open source. There are numerous embedded open source software solutions available on GitHub, GitLab and SourceForge that unfortunately do not properly address these challenges. As a result, companies hesitate to actually use it and the solution never lives up to its true potential. Consequently, the developer loses interest and stops maintaining it.

Part of the OpenBLT bootloader’s success is that Feaser backs it, to address exactly these challenges. The OpenBLT project is in a healthy state, showing a track record of ten years. No need to worry about the project being abandoned in the near future. Feaser oversees and vets all changes made to the code base. Feaser releases a new version stable version twice a year. One in the first part of January and one in the first part of July:

Illustration that explains the twice a year fixed release schedule of the OpenBLT bootloader, which attributes to its success.

Being on a fixed release schedule, makes it easy for you to schedule when to upgrade to the next stable release. With an active support and maintenance contract, Feaser even takes over the work for you: You can request Feaser to upgrade your previously delivered commercially licensed bootloader package to the latest stable release. The support and maintenance contract also gives you access to technical support and you’ll be informed, about a fix or workaround, whenever a critical bug was detected.

More of a tool than a product

Another factor that places the OpenBLT bootloader in a league of its own: It’s not just a product, it’s a tool. Sure, it’s a ready-made product that you can just use. However, it’s more than that. Thanks to its modular design and easy-to-understand source code you can expand, modify and customize its base functionality with little effort.

The PC tools used to initiate and monitor the actual firmware update process are built on top of a library, called LibOpenBLT. This LibOpenBLT library enables you to quickly develop your own firmware update tool, in the programming language of your choice. Perfect for creating a firmware update solution that seamlessly integrates with your possible existing tools. The PC tools MicroBoot and BootCommander, including the LibOpenBLT library, are of course also open source. So you can even change those to your liking.

In other words, you can sculpt the OpenBLT bootloader in a shape and form, which makes firmware updates in the most exotic system architectures possible. Let’s say you want to host the firmware update files for your embedded systems somewhere in the cloud. And locally you have an embedded Raspberry PI compute module tasked with performing firmware updates on your microcontrollers. A few of them on a CANopen network and then some on a Modbus RS485 network. Although not supported out-of-the-box, you can tweak the OpenBLT bootloader and its PC tools to make this happen.

Affordable pricing

The OpenBLT commercial license costs less than a 2-week salary of an embedded engineer in the Western world. That’s about half the price of competing closed sourced proprietary bootloaders. For that you get a solution that has been tried and tested for over a decade. Thousands of developers glanced over the code and I can’t even guess in how many products the OpenBLT bootloader currently runs.

Why is that? I learned early on in life that money in the bank does not equal happiness. As such, I adopted a simple lifestyle that satisfies me. I live by the mantra of “everything you own, ends up owning you”, I have little interest in shiny new things and I currently drive a 20-year old Volvo and love that thing. This approach also carries over into how I run Feaser. I keep the overhead low. No fancy office building to show off, just a simple room in the apartment where I live. No company car. Instead of hiring a full team of engineers, I try to handle most project work myself. Yet I have a good network of skilled, experienced and trustworthy embedded software contractors, willing to jump in when needed. This makes it possible for me to live comfortably, while keeping the product prices relatively low.

Wrapping up

When I first publicly published the OpenBLT bootloader ten years ago, one major concern I had was that I’d be bogged down with support questions. Nothing is further from the truth. I am highly impressed by the competence of embedded software engineers all over the world. Which leads me to the biggest success factor of the OpenBLT bootloader: You! OpenBLT wouldn’t be a success if it wasn’t for its users. A big thanks to everyone for trying out the bootloader and supporting the project by ordering the commercial license. I enjoy communicating with all of you and it even resulted in a few close friendships. I look forward to many more years working on the project. It still puts a smile on my face, the first time I get firmware updates working on a new piece of hardware.

This entry was posted in OpenBLT and tagged , , . Bookmark the permalink.