August 10, 2023

We're Rewriting Sdkbin

In light of the recent drama with the Moq project’s decision to try to solicit donations through the use of SponsorLink, I’ve decided to share some updates on Sdkbin - our NuGet marketplace for .NET developers that we launched in October, 2020.

The last update I shared on Sdkbin was February 2021 - Sdkbin has continued to be a major driver of revenue growth for us with our Phobos product and handles about 33% of our total revenue.

However, as I shared on Twitter yesterday - we are embarking on a project to rewrite Sdkbin in order to fulfill our mission of becoming the marketplace for OSS developers to build businesses around their technology.

Why so Few Sdkbin Updates?

One of the things I was proudest of with Sdkbin’s launch was it was the first software project I oversaw where I didn’t directly code anything myself - other than our Pulumi infrastructure we use for deploying and running on the cloud. I had hired an employee who had prior “startup CTO” experience to lead this project and he’d done some successful work with us on the Akka.NET project.

I developed the original plans and requirements for Sdkbin in Fall, 2019. We recognized even back in 2018 when we first launched Phobos (the product we sell through Sdkbin) that our manual fulfillment system was a dead-end and was in dire need of automation and improved customer-visibility.

I specced out a fulfillment system that combined the ability to process payments; provide access and visibility to multiple people in our customer organizations; and provision NuGet feeds with access to propreitary packages on the fly. I also decided that if we were going to build something like this in-house we could also re-purpose it as a marketplace for other developers facing the same types of logistical + operations hurdles we have at Petabridge.

We embarked on the project at the beginning of 2020 with a target delivery date of July 31st, 2020. Our first commit to the Sdkbin repository was on February 9th, 2020. Concurrently, we also worked on developing Phobos 1.0 and co-releasing it along with Sdkbin; Phobos 1.0 was a significant usability improvement over the initial versions we had developed and that was primarily my responsibility to code, test, and document.

I had planned on being more involved in the development of the project, but then COVID19 happened two-three weeks into the project.

This is how COVID impacted our business and me personally:

  1. Our onsite training business, 40% of our revenue in 2019, vanished instantly;
  2. Many of our biggest customers operated in the travel and sports betting businesses - two industries that were extremely impacted by the COVID lockdowns;
  3. My wedding was scheduled for April 3rd, 2020 originally - Texas banned all large in-person gatherings in March and effectively ended our wedding via force majeure, which triggered a series of disputes with our wedding planner and her vendors who fought us every step of the way to get our money back for services they couldn’t render even if they wanted to.

We ended up doing a small 10-person wedding a month later - unwinding one wedding and planning a new one, with some major uncertainty as to whether or not our out-of-state immediate family members, our only guests, could even attend (during this time Texas was outright blocking car traffic from Louisiana, where my wife and her family are from.) That was a major drain on my emotional and mental energy, to say the least.

The other major problem I had was keeping our company alive - I wear a lot of hats as CEO but my first duty is, forever and always, to our employees: payroll checks must go out on time and in their full amounts.

So to paint the picture for you - I suddenly found myself scrambling for remote consulting, support, and training gigs to support the members of our team working on Sdkbin, Akka.NET, and so on.

As a result of that, I committed the biggest engineering management mistake I’ve ever made: I didn’t get into the details (the code itself) with our developer very often. Working remotely across 7+ timezones didn’t help, but it was my decision to prioritize finding revenue in extreme market conditions over doing due diligence as an engineering leader.

Thus I left our developer unchecked; he made some flawed decisions with respect to domain assumptions, infrastructure choices, and architecture. We hit our second launch date in October; launched Phobos 1.0; and acquired our first paying customer on the platform within a week of launch.

And that’s when it became clear that the platform had some major problems - things were coupled together that shouldn’t be; unanticipated real-world use cases couldn’t be easily supported; and we’d accrued massive amounts of technical debt even though we’d just launched.

I’ll put together a livestream going over some of the problems this platform had at a technical level later, but in sum: there was zero chance I was going to subject other publishers to these problems until they were resolved for our own use cases first. For instance, dealing with the question of “what happens if a company demands to pay with a purchase order instead of Stripe” or “what happens if literally every contact at a B2B customer organization churns and all have to be replaced wiht the same tenant id” - real world matters for B2B vendors like us - couldn’t be easily addressed under Sdbkin’s current design.

Ultimately, we haven’t done a lot of Sdkbin updates because these issues have been economically impractical for us to resolve until recently.

In the end I’m grateful for some of the failures with Sdkbin because it taught me more about being a manager than successfully delivering products ever has - so we’ve radically changed our approach to how we manage the company, teams, software development, and more. But it’s been an embarssing and painful failure for me too.

Why a Rewrite?

If you’ve never read Joel Spolsky’s “Things You Should Never Do, Part I” - the opening is prophetic

Netscape 6.0 is finally going into its first public beta. There never was a version 5.0. The last major release, version 4.0, was released almost three years ago. Three years is an awfully long time in the Internet world. During this time, Netscape sat by, helplessly, as their market share plummeted.

It’s a bit smarmy of me to criticize them for waiting so long between releases. They didn’t do it on purpose, now, did they?

Well, yes. They did. They did it by making the single worst strategic mistake that any software company can make:

They decided to rewrite the code from scratch.

I wholeheartedly agree with this perspective - so why are we choosing to move forward with a rewrite anyway?

We decided that we want to experiment with some licensing changes for Phobos - namely trying to make it easier to support trials instead of the current “buy before you try” model we have today. And in order to do this we need to update our distribution system to incorporate different subscription / license tiers.

We spent about a month trying to determine if the current Sdkbin code was salvageable - it’s not.

The huge bespoke company framework (BCF) our original, and now former, developer built essentially coupled everything through a Byzantine network of AutoMapper, Microsoft.Extensions.DependencyInjection, environment variables scattered everywhere, Code-First Entity Framework, and some other homemade horrors that I won’t detail here.

The final straw for me was when I attempted to enable nullable in our code base and saw that 100% of our unit tests failed - and why is that? Because instead of testing against the SQL code-first Entity Framework snapshot it was designed to create a brand new in-memory SQL schema to test against instead. Meaning that for all practical purposes - these tests aren’t real and have no intrinsic value. They’re vaporware.

Again, I’ll do a livestream to go through some of the gruesome tech decisions later - but the point is: fixing this system is just throwing good money after bad. We’re better off starting with a clean slate with better practices, domain models, and infrastructure choices from day 1.

So that’s what we’re going to do - the project is under way now and we expect to relaunch late in 2023.

What Does This Mean for Publishers?

First and foremost, we’re going to spruce up Sdkbin to solve Petabridge’s problems:

  1. Accept multiple payment methods (i.e. purchase orders, credit cards, and beyond) - including the ability to add grace periods to expired subscriptions, co-terming, proration, etc;
  2. SSO support;
  3. Programmable email notifications in response to system events (i.e. automatically email customers when new versions are available);
  4. Multiple payment tiers per-product, including free trials;
  5. Better back-end procedures for handling turnover in customer organizations;
  6. Much more comprehensive financial and usage reporting; and
  7. Support offline license key generation and validation.

These are the immediate priorities for us - things we need to do for our own business purposes right away.

Next on the list, following that:

  1. Add support for selling / metering / fulfilling support plans to customers via Sdkbin and
  2. Add vendor onboarding procedures (i.e. IP validation, all legal / tax / banking boilerplate needed to process transactions).

I don’t have a timeframe for the latter two projects, as we have other large projects related to Akka.NET and Petabridge coming up after Sdkbin 2.0 goes live. But the support plan issue is an acute problem for us - our current manual fulfillment system leaves much to be desired there, so it will be dealt with.

Thank you to everyone for your patience and support - building a marketplace and an entire new line of business in public isn’t always glamorous or easy, but it’s what I enjoy waking up and doing every day. If you have any more questions or comments you can find me on Twitter, in the Akka.NET Discord, or in the comments below.

Discussion, links, and tweets

I'm the CTO and founder of Petabridge, where I'm making distributed programming for .NET developers easy by working on Akka.NET, Phobos, and more..