Open source

Open source has been a recurring part of my work for a long time. Most of these projects started because I had solved the same problem more than once and wanted the next application to start from a better place.

The result is a fairly mixed portfolio: configuration providers, Lambda libraries, testing helpers, API tooling, messaging frameworks, and a few command-line tools. Some became widely used, some are small utilities I still reach for myself, and some are mostly interesting as part of the path that led to the projects I build today.

Across the packages published under my personal NuGet account, the work has accumulated millions of downloads. I do not treat download count as the only measure of relevance, though. An old package can still be restored by long-lived applications, while a small package can remain useful even if it was never widely advertised.

Projects I actively maintain

AWS Secrets Manager configuration

A configuration provider for Microsoft.Extensions.Configuration that loads values directly from AWS Secrets Manager.

It started as a small integration around a very specific problem and became, by a large margin, my most widely used open-source project. It currently has 11.2M NuGet downloads and continues to see substantial usage years after its first release.

Version 2 was a substantial refresh rather than a compatibility-only update. It split secret loading into explicit discovery and known-secret modes, added built-in key mapping, and added OpenTelemetry tracing and metrics while keeping the package integrated with the normal .NET configuration model.

The project has also been used or covered by people and projects in the .NET community including Andrew Lock, Nick Chapsas, Milan Jovanović, Rahul Nath, and RavenDB. That external usage is more useful to me than the raw download number alone: it shows that the package ended up solving a problem other teams actually had.

Building Lambda functions in .NET

This project has been around in different forms for years. Its purpose has stayed fairly consistent: take care of repetitive Lambda plumbing while leaving application developers working with normal .NET and AWS concepts.

The previous generation of the library is still downloaded regularly despite having received no feature development for years. That was one of the reasons I preferred a substantial redesign over simply starting a new project.

Version 6 reorganizes the library around three semantic function models: request/response functions, one-way events, and record-processing functions. AWS-specific packages add the semantics required by integrations such as SQS, SNS, EventBridge, S3, DynamoDB Streams, Kinesis Streams, and Cognito. The templates can also opt into raw payload handling, Native AOT, and OpenTelemetry independently where supported.

Version 6.0 is now the stable line. It keeps the goal of the earlier library but with a cleaner hosting model, a broader set of AWS integrations, and templates that make features such as AOT and observability opt-in rather than forcing a different way of writing the handler.

MinimalOpenAPI

My current take on contract-first APIs with ASP.NET Core Minimal APIs.

The OpenAPI document remains the source of truth. A source generator produces contracts, typed handler base classes, dependency-injection registration, endpoint mapping, and OpenAPI metadata, while the application supplies the actual behavior.

Version 1.0 is the first stable release. It supports OpenAPI 3.0 and 3.1 documents in YAML or JSON, multiple documents, a growing set of schema constructs, typed results, multipart form uploads, and compile-time diagnostics for invalid contracts and generated-name collisions.

It is a much younger project than the libraries above, so I do not think its download count says much yet. It does, however, represent the kind of tooling I am most interested in building today: tooling that removes mechanics without taking ownership of the application away from the developer.

Object configuration

A provider that lets concrete objects participate in the normal .NET configuration pipeline.

Version 4 turned what had been a small convenience library into something I am much happier to recommend. The API is now centered on System.Text.Json, supports source-generated JsonTypeInfo<T> metadata, and builds on the standard JSON stream configuration provider instead of maintaining a separate JSON-to-configuration implementation.

The addition I use most is AddObjectAsFallback: it lets defaults live in code while still allowing appsettings.json, environment variables, command-line arguments, and any other higher-priority provider to override them through the normal IConfiguration pipeline.

Testing tools I actually use

A separate family of packages grew out of how I use AutoFixture. I prefer tests where the values explicitly written in the test are the values relevant to the behavior being exercised. The rest can usually be generated.

MockHttp

The integration removes much of the setup needed when testing code built around HttpClient. It has accumulated 378K downloads, and one notable public consumer is the Bitwarden server.

WebApplicationFactory and gRPC

WebApplicationFactory
gRPC

These integrations have much smaller public download numbers, but they are not historical packages for me. I still use both in current projects when writing integration and component tests.

That is a useful reminder that package popularity and package relevance are different things.

Small tools that stayed useful

Hyde

A .NET CLI for managing content in Jekyll sites. It came from my own blogging workflow and was intended to make creating and managing posts and pages feel closer to using a purpose-built command-line tool.

I do not actively develop it today, but it is one of the projects that pushed my open-source work beyond application libraries and into developer tooling.

CodeWorkspaceTool

A command-line tool for managing VS Code multi-root workspace files, roughly the way dotnet sln manages project references in a solution. It can create workspaces and manage folders, recommended extensions, and settings.

It is another example of turning a repetitive development workflow into a small reusable tool rather than continuing to edit the same JSON structure by hand.

Nybus: when I built a messaging framework

Nybus was a much larger undertaking. It was an application framework for message-based systems built around an explicit distinction between commands and events, with infrastructure integrations kept outside the contracts used by application code.

There were two substantially different generations of the framework, with packages for abstractions, RabbitMQ, dependency-injection containers, logging, Reactive Extensions, MassTransit, and other integrations.

Nybus is no longer an active focus and I would not present it as a framework to start a new system on today. Its packages still have a small but persistent download tail, though, and several ideas that matter to me today were already visible there: keep business-facing abstractions small, push infrastructure concerns outward, and remove repetitive plumbing without erasing the semantics of the underlying system.

The Insight Architectures library portfolio

When I founded Insight Architectures, I also tried to establish the company as a technical brand rather than publishing everything under my personal identity.

The result was a set of public repositories and NuGet packages covering general .NET utilities, Microsoft.Extensions integrations, testing helpers, reusable model types, ASP.NET Core and gRPC helpers, project templates, and Terraform modules.

The most widely downloaded package from that period is InsightArchitectures.Extensions.Http.Configuration, which configures HTTP-related behavior through the Microsoft.Extensions ecosystem.

Most of the IAAB package portfolio is historical now. I still find the experiment interesting because it was an attempt to make a consultancy produce reusable engineering assets rather than only consulting deliverables.

Usage can outlive the design

One package that surprised me while revisiting this portfolio is Kralizek.Extensions.Logging. It still receives regular downloads despite being old and despite containing patterns I would not choose today.

That kind of continued usage can come from long-lived systems and build pipelines that keep restoring a dependency long after its design has stopped evolving. Public NuGet statistics can show that consumption continues, but they cannot tell me exactly who is still using it or why.

That is why I do not use the latest commit date or lifetime download count as a proxy for whether I still recommend a project. When revisiting older work I care about several different signals: recent download trends, downstream packages and public consumers, whether I still use the project myself, and whether I still agree with the design.

What connects the projects

The technologies vary, but a lot of this work sits in the same place: the boundary between application code and frameworks or infrastructure.

Messaging, configuration, Lambda hosting, test setup, OpenAPI generation, and developer tools all create repetitive mechanics that can obscure the decisions that actually matter. The projects I keep finding useful are usually the ones that remove those mechanics while keeping the important choices visible.

You can find the broader collection of projects under Kralizek on GitHub, Insight Architectures, and the Nybus project.