How and why we wrote our first open source project
Choosing to go the open source route is not always something that is high on the agenda for a company, but it can come with a number of benefits.
The background
As part of our migration away from a monolith into microservices, there are a number of packages that get used in a high percentage, if not all of our microservices.
One of these such packages was one created by a maintainer (thanks if you are reading this!). It was a Serilog Sink for log messages between Serilog and Azure Queue Storage.
We had previously been using this existing open source library throughout our codebase, however as part of a spring upgrade spree, we came across the package which had a dependency on .net 2.1 core which we wanted to update and remove as it was flagged in our security vulnerability scan. The repository had since been deleted from GitHub, and only the package remained listed on Nuget.org. Once something is up on Nuget.org, it can be delisted from the search results but not deleted, which makes sense as otherwise someone could remove a package and cause large scale disruption. As a result, we were able to continue using this package even though it was no longer maintained.
We therefore needed a way to create a new version of this library, and one that would use the latest versions and libraries.
The Process
The first part of the process was to understand what the current library was doing under the hood. JetBraines have a great, free tool called dotPeek which decompiles .NET assemblies into C#.
In using this we could then get a look at the code, to ensure that when we built our own library we didn’t miss out on any required features, or unknowingly break a feature for anyone else that may come to use it.
After this, we went through the relevant Microsoft documentation on writing to an Azure Queue Storage, and as it turns out the old package was using a deprecated Nuget package. Instead, Microsoft had a newer and simpler packaged called Azure.Storage.Queues.
We then proceeded to rewrite the functionality with the new Azure package, which ended up being a simpler implementation. However, we did run into a few gotchas.
Gotchas
There were a couple of gotchas that we did experience in making our first public facing Nuget package. The first was during an initial testing phase we pushed a package up with a different namespace, to check that our build process was working. As you can’t remove from Nuget and only delist, we do have a blank package floating around, and one which was downloaded a few hundred times (by bots/mirrors one would imagine). This has now been delisted.
The other gotcha was that initially work was begun on a .NET library version 2.1. It then became clear that actually 2.0 was the version that would work best, as it supported older .NET framework versions. This was important to us to have this flexibility, and mostly likely many people using it.
In fact, Microsoft note themselves that:
We recommend you target .NET Standard 2.0, unless you need to support an earlier version. Most general-purpose libraries should not need APIs outside of .NET Standard 2.0. .NET Standard 2.0 is supported by all modern platforms and is the recommended way to support multiple platforms with one target.
Also when announcing .NET Standard 2.1 on their dev blogs website, it also mentions:
Library authors who need to support .NET Framework customers should stay on .NET Standard 2.0. In fact, most libraries should be able to stay on .NET Standard 2.0, as the API additions are largely for advanced scenarios.
So the TL:DR is that use .NET standard 2.0 for libraries for maximum support.
So, what are the benefits of going down the open source route?
Benefits
Keeping our code secure
One of the useful things about making a package open source, is that you may end up with collection of people who are able to collaborate and assist with maintenance. This means less reliance on your own core team, which can only be a good thing.
It also means there are more eyes on the repository in case of any vulnerabilities that are found and need updating, helping to keep it more secure.
Additional features
Similarly to helping with maintenance of secure code, having developers from outside your organization work together on an open source package means you are likely to have additional features as a result.
Added bug finding
With more people using and contributing to a package, this means there are different ways it is being implemented, which means more ability to find bugs. If you have an internal package that has a bug that appears very infrequently, having more people use this package increases the chance of finding and also helping to solve bugs in the code.
Stronger code
Having a diverse group of people contributing to an open source package means you will naturally end up with stronger code. This should translate into less bugs, and therefore less strain on individual organizations in order to fix issues.
Working together in order to help each other on common tasks, particularly in an area we endearingly call ‘plumbing’, is something that provides a number of benefits for everyone involved.
Time spent developing open source means more time for an organization to really focus on their execution and value propositions, so everyone wins when we work together.
Contributing to the project
If you want to help contribute to the project head on over to the Serilog.Sinks.AzureQueueStoragev2 GitHub repository and raise an issue or PR. Cheers!
