I’ve written several posts recently about creating sustainable open source projects by treating them like proper businesses - my journey for the past 5-6 years since founding Petabridge has been a quest to find a way to create sustainable, profitable business models built on top of the open source software I’ve spent the last 6-7 years developing.
The greatest obstacle to building sustainable open source businesses today is creating the infrastructure required to sell products + services; fulfill those orders; handle billing; and hardest of all - get discovered by customers. Each of these areas requires building repeatable systems in areas that are mostly unfamiliar to software developers.
Here we go again. “The Day AppGet Died” - the short version: OSS developer fills a hole in the Windows ecosystem, Microsoft offers him a job to work on this kind of product inside the company, ghosts him, releases their competing product which appears to have borrowed heavily from his designs, doesn’t attribute original developer’s work, Internet gets mad, Microsoft gives a non-apology apology, and maybe some kind of resolution.
The moral of the story:
Another example story on why you can build either something on Microsoft ecosystem or build something popular, but never do both.— Bartosz Sypytkowski (@Horusiath) May 27, 2020
David Fowler and Damian Edwards, some of the leaders of the .NET ecosystem at Microsoft, more or less concurred:
If I had to boil it down I'd say that .NET as a platform...
In my last post about “The Next Decade of .NET Open Source” I alluded to a future blog post about open source sustainability. This is it.
Some background: in January 2015, fresh off of the very public failure of MarkedUp, my first company, and the total destruction of my life savings at the ripe age of 29 - I founded my current company Petabridge. We’re five years old now, growing rapidly, and we’re entirely self-funded.
Petabridge is a business built entirely around supporting the users of its .NET Open Source projects, primarily the Akka.NET project, which I founded out of necessity in order to build a real-time marketing automation product at my previous business.
That’s the origin story of how I got here and why I’m delighted to hear others start talking more actively about...
I love SourceLink - it’s fast becoming a standard practice to include SourceLink support in all open source NuGet packages in order to make them easier to debug. We’ve included SourceLink support in Akka.NET and some of our other projects for some time now.
However, I’m embarassed to admit that I’ve never been able to remember how to get this to work properly each time I switch machines or projects. So, I decided to document how to do it.
Step 0 - Verify That Your Third Party NuGet Packages Actually Support SourceLink
Before you go through the trouble of configuring Visual Studio to support SourceLink you’ll want to make sure that the third party package you’re trying to debug actually supports it.
The official Microsoft documentation on SourceLink has some guidance for how to do this, but odds are high that popular NuGet packages (i.e. ASP.NET,...
Over the past week there’s been a ton of chatter about the state of the .NET ecosystem and, more specifically, as to whether or not its OSS ecosystem is healthy and sustainable over the long term.
I won’t bother with the details, but the substantive criticisms amount to:
- If you build a popular OSS technology in .NET Microsoft will simply cannibalize it and roll it into a 1st party feature (i.e. Entity Framework cannibalizing NHibernate, built-in DI in ASP.NET Core, etc;)
- .NET users are still overwhelmingly Microsoft-centric - i.e. if Microsoft told its users to store all of their passwords in plain text at least 30% of them would blindly do it because Microsoft said so without considering any second opinions;
- The .NET ecosystem doesn’t built anything “cool” - there’s no innovation here and thus no real way to attract fresh ideas and younger talent to the ecosystem; and ...
This is largely the text of an issue I posted related to the .NET Foundation’s new proposed Maturity Ladder for .NET OSS projects. I am fully supportive of the .NET Foundation’s stated mission and wrote this in the hopes of trying to help it achieve that through a little tough love.
After reading (.NET Foundation Directory) Jon Galloway’s reply here I want to raise a fundamental problem that exists with the .NET Foundation in its current form that makes some portions of the ladder proposal distasteful, in my eyes as both the proprietor of an independent .NET OSS business, a project contributor, and as someone who deeply cares about the success of the .NET OSS ecosystem as a whole (it’s why I started Petabridge.)
Microsoft and the .NET Foundation are effectively joined at the hip. Its day to day operations and run by largely by Microsoft employees...
In my professional life, I’ve actively conditioned myself to tolerate and accept risks when necessary. Risk tolerance is something that can be learned and taught. But risk tolerance is fundamentally a contextual matter - two people with identical means and skills can have totally different reactions to the stressors risk presents.
There are people who will go skydiving but won’t ever, ever leave their stable corporate job that they hate because the alternatives terrify them. There are people like me who won’t jump out of a perfectly good plane, even at gunpoint, but feel totally comfortable entering work situations even with uncertain economic outcomes.
I’m generally confident and assertive, but my biggest regrets in life have come from situations where I failed to be either. In these moments I make a common mistake: when I weigh my choices, I invent additional possible negative outcomes that don’t actually exist.
Chief among the values prized by fellow millennials is comfort. It’s reflected in our more casual dress and our increasing preference for impersonal forms of communication, such as text or Slack. Our desire to form self-reinforcing informational and social bubbles, where we can limit our exposure to different and potentially disagreeable ideas, is fundamentally driven by a desire to avoid discomfort.
Our comfort fetish began with the “self esteem” movement in the early 1990s, when we were elementary aged-children. It culminated into the (rightfully) maligned “participation trophy” culture. And the trend simply continued on under its own momentum from there, leading to the rise of Safetyism and other developmentally self-destructive movements. The pursuit of comfort above all else puts us in a position where we simply sit through and endure the bad hands dealt to us by circumstance.
It was roughly a year ago this week that I fled California in pursuit of greener economic pastures. I came to Texas an economic refugee; despite running a successful business in California for a number of years I watched my profit steadily fall beneath the relentless tide of cost of living inflation, taxes, and so on.
It’s a move I’d been wanting to make for years but timing and circumstance stayed my hand until April 2017. And it was a difficult choice too - I was leaving behind my family in California, who are a short drive away from where I lived in Los Angeles. And I really loved LA itself - it’s a great city where you could do something different every day and not see a tenth of it by the time you die.
I made the choice to leave, happily, because it’s backed by intention: I’m not...
I spend a lot of my professional time training other software developers on how to build next-generation applications. Distributed and concurrent systems; stream processing; stateful web applications; soft real-time applications; and so forth. Cutting edge stuff for the majority of my industry.
One of the huge advantages of inexperience, such as when you first graduate from school, is your default state of being with the world is one of perpetually learning and adopting new skills and techniques. You’re not intimidated by taking on a project with lots of unknowns because… every project feels that way during the beginning of your career. But once you’ve been in your industry for a few years you pick up a few things: tools, tricks of the trade, techniques, pitfalls, preferences, methodologies, and so forth.
Fast forward to your five, ten, or fifteen year mark in your career you’ll run into what is an existential...