Almost 15 years ago, I was working as a developer on a gigantic command and control system developed in a language called Ada. This is what Wikipedia has to say about Ada:

These were very important attributes for a system that needed to be super reliable, highly performant, and very scalable. Little did I realize at that time how profound an effect this relatively unknown programming language would have on the rest of my career.

In my next company, a software development firm—the kind that does turnkey projects for its customers—I continued my focus on command and control systems, this time using the fairly new .NET platform from Microsoft. The thing was that many of the abilities that I'd come to rely on in Ada were (to me) curiously absent from .NET.

Like any good craftsman who has gotten used to a certain tool, I started looking around for a replacement, and when I couldn't find one, I went and made it myself.

Although the main message from Microsoft at the time was all about XML Web Services and .NET Remoting, I found that there was support for a message passing model in .NET that was actually built on a piece of infrastructure that was considerably older (originally built in the NT 3.5.1 days, but released with NT 4.0 in 1997). At that time, MSMQ had made it to version 3.0 which, later on, I learned was the magic number when it came to stability of software built by Microsoft.

Still, I found the System Messaging API to be a little too close to the metal for me to feel comfortable using it directly from my application logic, so I created a wrapper library, which gave me some much needed abstraction.

As I moved from one project to the next, I found this little library to be more and more useful and kept on extending and refining it. The developers in my teams seemed to like working with it as well.

After the third or fourth project, I decided to approach the company's management, suggesting that we should consider turning this infrastructure into a product. Seeing how useful it was to us on our projects, I figured that it was a no-brainer.

It turned out that this company had gone down the productization path in the past and had gotten badly burned in the process. As a result, they were very hesitant to make the same mistake again. Realizing that it wasn't going to happen, I managed to get permission to release the infrastructure to the world as an open source project, but only after legal confirmation that there would be no support or other liabilities to the company.

Thus, in 2007, NServiceBus was born.

This also happened to be the time when I started transitioning into my own private consulting practice.

As I continued to use NServiceBus in my work projects, I kept tweaking and expanding it. Version numbers didn't mean a whole lot, and through 2008, the version progressed rapidly from 1.6.1 to a release candidate of 1.9. If it worked on my project, I considered it worthy to ship.

Documentation was practically nonexistent and developers leaned pretty heavily on samples to figure out what the software did, asking questions on the discussion group when they ran into cryptic error messages (of which there were many).

In 2008, the 5-day format of my Advanced Distributed Systems Design course was launched, which was an extension of the 2-day workshop on the same topics I had been teaching since 2006. This course was based on many of the learnings from my old Ada days and continues to serve as the architectural underpinning of much of NServiceBus to this day.

April 2009 brought some stability with the final release of version 1.9 but came with a marked increase in the amount of consulting and training I was doing. This was great for me as I could finally afford to turn down work in order to continue the development of NServiceBus. This worked out great and in March 2010, the much-heralded NServiceBus 2.0 was finally released.

By almost every measure, things were going great. More companies were adopting NServiceBus and bringing me in for consulting. The Advanced Distributed Systems Design course was getting quite popular, and for a while, I was teaching it almost once a month in a different country around the world. Unfortunately, almost 6 months had gone by without any meaningful development on the code base.

Then it hit me that if another year or two would pass by in this manner, NServiceBus would start to get stale and the companies that had used it in their systems would eventually have to replace it with something else (costing them quite a lot of time and money).

I had lived through this story several times as a consumer of open source projects. As long as the project wasn't too intertwined in our system, it wasn't too painful to remove it. The thing was that NServiceBus was a fairly large framework that supported broad cross-sections of both client-side and server-side logic, so there would be no simple way to replace it.

I tried to figure out how I could guarantee that the development of the code base would stay a priority, yet as long as my primary source of revenue was services (consulting and training), I couldn't see how it would work. The only solution seemed to be to start charging money for NServiceBus licenses. Although larger companies were able to keep an open source core and sell other products around it, I hadn't seen or heard of any one-person operations that had been able to bootstrap their way into that.

I had no idea whether this would work, and whether the open source community that had supported me all this time would accept it or turn their backs on me, but I felt that it needed to be done. Unless there was revenue coming in directly from the features of the product, it wouldn't have a future.

Therefore, in late 2010, I founded the NServiceBus company and steeled myself for the worst.