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
Kralizek.Extensions.Configuration.AWSSecretsManager
<a href="https://www.nuget.org/packages/Kralizek.Extensions.Configuration.AWSSecretsManager" aria-label="Total downloads of Kralizek.Extensions.Configuration.AWSSecretsManager">
<img src="https://img.shields.io/nuget/dt/Kralizek.Extensions.Configuration.AWSSecretsManager?label=downloads" alt="Total downloads of Kralizek.Extensions.Configuration.AWSSecretsManager">
</a>
</span>
Kralizek.Extensions.Configuration.AWSSecretsManager is 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 11M NuGet downloads and continues to see substantial usage years after its first release.
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
<a href="https://www.nuget.org/packages/Kralizek.Lambda.Templates" aria-label="Latest prerelease version of Kralizek.Lambda.Templates">
<img src="https://img.shields.io/nuget/vpre/Kralizek.Lambda.Templates?label=prerelease" alt="Latest prerelease version of Kralizek.Lambda.Templates">
</a>
<a href="https://www.nuget.org/packages/Kralizek.Lambda.Template" aria-label="Total downloads of Kralizek.Lambda.Template">
<img src="https://img.shields.io/nuget/dt/Kralizek.Lambda.Template?label=downloads" alt="Total downloads of Kralizek.Lambda.Template">
</a>
</span>
AWS Lambda Sharp Template 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.
The current v6 line is still prerelease, so for this project the prerelease badge above is the version that best represents where the work is going. The download badge, on the other hand, reflects the core Kralizek.Lambda.Template package rather than the template package itself.
MinimalOpenAPI
<a href="https://www.nuget.org/packages/MinimalOpenAPI" aria-label="Total downloads of MinimalOpenAPI">
<img src="https://img.shields.io/nuget/dt/MinimalOpenAPI?label=downloads" alt="Total downloads of MinimalOpenAPI">
</a>
</span>
MinimalOpenAPI is 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.
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.
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
Kralizek.AutoFixture.Extensions.MockHttp
<a href="https://www.nuget.org/packages/Kralizek.AutoFixture.Extensions.MockHttp" aria-label="Total downloads of Kralizek.AutoFixture.Extensions.MockHttp">
<img src="https://img.shields.io/nuget/dt/Kralizek.AutoFixture.Extensions.MockHttp?label=downloads" alt="Total downloads of Kralizek.AutoFixture.Extensions.MockHttp">
</a>
</span>
The MockHttp integration removes much of the setup needed when testing code built around HttpClient. It has accumulated 371K downloads, and one notable public consumer is the Bitwarden server.
WebApplicationFactory and gRPC
Kralizek.AutoFixture.Extensions.AspNetCore.WebApplicationFactory
</span>
Kralizek.AutoFixture.Extensions.Grpc
</span>
The WebApplicationFactory and gRPC 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
Object configuration
Kralizek.Extensions.Configuration.Objects
</span>
ObjectConfigurationExtensions is a small provider that lets concrete objects participate in the normal .NET configuration pipeline.
I never really promoted it, but I still use it whenever I want hardcoded values to flow through IConfiguration rather than introducing a separate configuration mechanism just for them. It is a good example of a package that does not need broad adoption to keep earning its place.
Hyde
</span>
Hyde is 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
</span>
CodeWorkspaceTool manages VS Code multi-root workspace files from the command line, 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
<a href="https://www.nuget.org/packages/Nybus" aria-label="Total downloads of Nybus">
<img src="https://img.shields.io/nuget/dt/Nybus?label=downloads" alt="Total downloads of Nybus">
</a>
</span>
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.
InsightArchitectures.Extensions.Http.Configuration
<a href="https://www.nuget.org/packages/InsightArchitectures.Extensions.Http.Configuration" aria-label="Total downloads of InsightArchitectures.Extensions.Http.Configuration">
<img src="https://img.shields.io/nuget/dt/InsightArchitectures.Extensions.Http.Configuration?label=downloads" alt="Total downloads of InsightArchitectures.Extensions.Http.Configuration">
</a>
</span>
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
<a href="https://www.nuget.org/packages/Kralizek.Extensions.Logging" aria-label="Total downloads of Kralizek.Extensions.Logging">
<img src="https://img.shields.io/nuget/dt/Kralizek.Extensions.Logging?label=downloads" alt="Total downloads of Kralizek.Extensions.Logging">
</a>
</span>
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.