Support Open Source

Last week brought a little bit of drama to the dotnet development community. The popular open source testing framework Moq briefly moved out of open source and into shareware without much warning. Daniel Cazzulino, the maintainer of Moq, has already indicated the next generation of Moq will have some form of commercial license. The way it was done was inelegant but the reason was all to common: Cazzulino decided he needed more financial support to continue. While I think he could have handled it better, I don’t blame him — we all have bills to pay. The lack of financial support for people who maintain key software is an understated risk in the modern software landscape. Every organization which builds or uses modern software is relying on a massive ecosystem of open source software (OSS). Most enterprises do zero to help those OSS teams who in turn rely on people who are basically volunteers.

What do we expect a volunteer team will do when they are looking at their own bank accounts and realizing the extra hours they put in for free are making other people money? What happens when they conclude that they can’t really support this free product and work a full-time job to pay the bills? What are they to do when they reach the back nine of middle age and discover their retirement prospects don’t look great?

Choosing Tools to Make Your Life Harder

In this article, I discuss some of my thoughts on how tools can make some tasks harder while making others easier and what it means for our organizations. I also go into why adopting a tool that makes some tasks harder may not be all that bad and touch on a strategy or two for managing these tools. I’m considering this a first public draft rather than a final article. I am curious how you all see it.

Unselfish Tasks

Your team has a list of tasks that need to get done. How do you decide who does what? It seems simple on the surface but as soon as you start thinking about it, it becomes more and more daunting. This time around, I’ll discuss how I prefer to do it and why. Hint: it doesn’t start with just assigning everything and hoping it gets done.

Musing on Construction as a Metaphor for Software Development

We often use building construction as a metaphor for software development. This time around, I explore the aptness of this metaphor a little bit in light of my own background in both.

Rust in Your Code

I starrted dabbling in the new-ish programming language Rust a few months ago. While Rust reached 1.0 in 2015, eight years old is still a baby among programming languages. Nearly everyone taking on the topic “why Rust” will cover the same key features: memory/thread safety, performance, and the ease of distributing applications built with it. Those are the “sell it to the CTO” features. In this post, I cover some of the other features that are a little less flashy but that I think make Rust a pleasure to work with. Fair warning: this post is tech heavy.