I don’t know about you, but my 2020 didn’t quite go the way I planned, Among other things, my grand OSS plans really didn’t go the way I hoped. Besides the obvious issues caused by the pandemic, I was extremely busy at work most of the year on projects unrelated to any of my OSS projects and just didn’t have the energy or time to do much outside of work.
Coming into the new year though, my workload has leveled out and I’m re-charged from the holidays. Moreover, I’m going to get to use some of my OSS tools for at least one client next year and that’s helping my enthusiasm level. At the end of the day though, I still enjoy the creative aspect of my OSS work and I’m ready to get things moving again.
Here’s what I’m hoping to accomplish in 2021:
Marten V4.0 is already heavily underway with huge improvements ongoing for its Event Sourcing support. We’ve also had some significant success improving the Linq querying support and performance all around by almost doing a full re-write of Marten’s internals. There’s a lot more to do yet, but I’m hopeful that Marten V4.0 will be released in the 1st quarter of 2021.
In the slightly longer term, the Marten core team is talking about ways to possibly monetize Marten through either add on products or a services model of some sort. I’m also talking with my Calavista colleagues about about how we might create service offerings around Marten (scalable cloud hosting for Marten, DevOps guidance, migration projects?).
Regardless, Marten is getting the lion’s share of my attention for the time being and I’m excited about the work we have in flight.
After having worked on it for over half a decade, I actually did release Jasper V1.0 last year! But it was during the first awful wave of Covid-19 and it just got lost in the shuffle of everything else going on. I also didn’t promote it very much.
I’m going to change that this year and make a big push to blog about it and promote it. I think there’s a lot of possible synergy between Jasper and Marten to build out CQRS architectures on .Net.
Development wise, I’m hoping to:
- Add end to end open telemetry tracing support
- Async API standard support (roughly Swagger for messaging based architectures if I’m understanding things correctly)
- Kafka & Pulsar support has been basically done for 6 months through Jarrod‘s hard work.
- Performance optimizations
- A circuit breaker error handling option at the transport layer similar to what MassTransit just added here: https://masstransit-project.com/advanced/middleware/killswitch.html. This would have been an extremely useful feature to have had last year for a client, and I’ve wanted it in Jasper ever since
- Jasper has an unpublished add on for building HTTP services in ASP.Net Core with a very lightweight “Endpoint” model that I’d like to finish, document, and release. It’s more or less the old FubuMVC style of HTTP handlers, but completely built on an ASP.Net Core foundation rather than its own framework.
Storyteller has been completely dormant as a project last year, but I know I’ve got a project coming up at work next year where it could be a great fit. I had started a lot of work a couple years ago for a big V6 overhaul of Storyteller. If and when I’m able, I’d like to dust off those plans and revamp Storyteller this year, but with a twist.
Instead of fighting the overwhelming tide, I think Storyteller will finally embrace the Gherkin specification language. I think this is probably a no-brainer decision to just opt into something that lots of people already understand and common development tools like JetBrains Rider or VS Code already have first class support for Gherkin.
I still think there’s value in having the Storyteller user interface even with the Gherkin support, so I’ll be looking at an all new client that tries to take the things that worked with the huge Storyteller 3.0 re-write a few years ago and puts that in a more modern shell. The current client is a hodgepodge of very early React.js and Redux, and I’d honestly want to tackle a re-write mostly to update my own UI/UX skillset. I’m still leaning toward using the very latest React.js, but I’ve at least looked at Blazor and sort of following MAUI.
I’ve mostly been just keeping up with bugs, pull requests, and new .Net versions for Lamar. At some point, Lamar needs support for IAsyncDisposable. I also get plenty of questions about how to override Lamar service registrations during integration testing scenarios, which is tricky just because of the weird gyrations that go on with HostBuilder bootstrapping and external IoC containers. There is some existing functionality in Lamar that could be useful for this, but I need to document it.
I might think about cutting the existing LamarCodeGeneration and LamarCompiler projects to their own first class library status because they’re developing a life of their own independent from Lamar. LamarCodeGeneration might be helpful for authoring source generators in .Net.
There was just a wee bit of work to move Oakton and Oakton.AspNetCore to .Net 5.0. In the new year I think I’d like to just merge those two projects into one single library, and look at using Spectre Console to make the output of the built in environment test commands look a helluva lot spiffier and easier to read.
Alba
Alba just got .Net 5.0 support. I’ll get a chance to use Alba on a client project this year to do HTTP API testing, and we’ll see if that leads to any new work.
StructureMap
I’ll occasionally answer StructureMap questions as they come in, but that’s it. I’ll be helping one of Calavista’s clients migrate from StructureMap to Lamar in 2021, so I’ll be using it for work at least.
FubuMVC
It’s still dead as a door knob. There are plenty of bits of FubuMVC floating around in Oakton, Alba, Jasper, and Baseline though.
The Shade Tree Developer 
Love these plans! A question that might help us understand your plans for the Storyteller direction: If you’re embracing Gherkin, and SpecFlow already supports Gherkin (and generating lists of scenario steps for external stakeholders), how would you like Storyteller to differentiate itself in (forgive the pun) this new chapter?
I think there’s plenty of room for tools in this space, but I’ve spent a lot of time with SpecFlow recently, and so I’d love more of your thoughts on what alternative approaches you’d like to see offered. (As they’re also OSS, I wonder if there’s an opportunity to share common elements, e.g. tooling / libraries around Gherkin parsing.)
I almost addressed the “why not just use SpecFlow?” in the post. I will most likely take a look at their parsing support for ideas. For very basic scenarios, I doubt there’d be much difference between Storyteller and SpecFlow. For data intensive tests and more complicated test automation scenarios though, I think there’s a *lot* of valuable functionality in Storyteller today that does not exist in SpecFlow that I still want for my projects. The existing Storyteller approach to rendering spec results and being able to correlate instrumentation to test runs is invaluable for example.