The Value of a JasperFx Support Contract

JasperFx Software is the company I founded a little over two years ago to create an Open Core business model around the “Critter Stack” suite of open source tools (primarily Marten and Wolverine, with some smaller supporting tools). So far, our main sources of revenue (right now it’s myself with contributions from Babu Annamalai, but we’d sure like to grow soon!) have been technical consulting to help our customers get the best possible results from Marten or Wolverine, custom feature development within the tools, and ongoing support contracts.

Just by the nature of what they are for (asynchronous messaging, event sourcing, and data persistence), the “Critter Stack” tools have to be considered a mission critical part of your technical infrastructure. You can pick these tools off the shelf knowing that there is a company and community behind the tools even though they’re free to use through the permissive MIT license. To that point, a support plan from JasperFx Software gives you the piece of mind to use these tools knowing that you have ready access to the technical experts for questions or to have any problems you encounter with the tools addressed.

The support contracts include a dedicated, private Discord or Slack room for your company for relatively quick response (our SLA is 24 hours, but we generally answer much faster than that). We aren’t just there for defects, we’re (JasperFx) also there to answer questions and to advise you on best usages of the tools as you need within the bounds of the contract. I’ve frequently jumped on Zoom or Teams calls with our customers for trickier questions or just when it takes more communication to really get to a solution for our customers. I can proudly say that every single JasperFx support customer has renewed their yearly support plan when the first year was up so far.

Just to give you an idea of what kind of issues JasperFx can help you with, the most common issues have been:

  • Concurrency, concurrency, concurrency. Sometimes it’s helping users design queueing and messaging topologies to ameliorate concurrent access, sometimes it’s helping them to leverage Marten’s optimistic and pessimistic locking support, and sometimes it’s helping to design Wolverine resiliency strategies.
  • Guidance on Event Sourcing usage within the Critter Stack, with designing event projections being a particularly common source of questions
  • Multi-tenancy usage. Marten and Wolverine both have unusually strong support for multi-tenancy scenarios as a result of our users coming up with more and more scenarios for us!
  • Automated testing, both how to leverage Wolverine capabilities to write more easily testable business logic code and how to use both Marten and Wolverine’s built in support for integration testing
  • Plenty of issues around messaging brokers and messaging patterns

There’s been some consternation about some other widely used .NET OSS tools moving to commercial licenses that have caused many people to proclaim that they should just roll their own tools instead of paying for a commercial tool or using an OSS tool off the shelf that might become commercial down the road. I’m going to suggest a little different thinking.

Before you try to roll your own Event Sourcing tool, just know that Marten is over a decade old, it’s well documented, and it’s the most widely used Event Sourcing tool in the .NET ecosystem (by Nuget downloads, and it’s not really close at all). Moreover, you get the benefit of a tool that’s been beaten on and solves a lot of very real, and quite complex problems with Event Sourcing usage that you may not even know you’re going to have.

Before you “just write your own abstraction over messaging brokers”, know that tools like Wolverine do a lot more than just abstract away tools like Rabbit MQ or Azure Service Bus. Resiliency features — and some of that is quite more complicated than just plopping in Polly, Open Telemetry tracing, other instrumentation, dealing with serialization, stateful saga workflows, multi-tenancy, scheduled message execution, and transactional inbox/outbox features are just some of the built in capabilities that Wolverine provides. And besides all the normal features you’d expect out of a messaging tool in .NET, Wolverine potentially does much, much more within your application code to simplify your development efforts. The people who really embrace Wolverine’s different approach to application code love how it drastically reduces code ceremony compared to more common Clean/Onion Architecture layered approaches using other competitors. Having an ongoing relationship through a JasperFx Software support contract will only help you wring out the very most from your Wolverine usage.

Leave a comment