On Tuesday, January 5th 2021 my grandfather, James Chester Roush, passed away in his retirement community in San Diego, California, peacefully in his sleep. He was 96 years old. He was a World War II veteran, serving as a navigator-bombardier for the US Army Air Corps on a B-26 Martin Marauder stationed out of Sardinia and later, Dijon France.
My grandfather was a personal hero of mine - a man I admired and looked up to throughout my life. I loved his stories about his early life, his time in the war, his hunting and fishing adventures, and in their totality: discovering the lost, rugged world he was born into through his lived experiences. He witnessed the amazing transformation the 20th and 21st centuries brought to our world. But first, his life began with one hardship after another.
I’ve written before about how to start contributing to OSS and I wrote for the Petabridge blog about “How to Use Github Professionally” - both of those posts were aimed at helping developers who had experience working in private software organizations bring their experience and passion into open source software and more specifically, how to use Github as a platform to do that effectively.
This post is aimed at a different audience: developers who want to play the team sport of software. Regardless of your experience level you can always benefit from improving your ability to work with the other developers.
There are entire volumes of books written on this subject, so I’m not going to broach everything - but I hope you find this approachable, helpful, and useful.
“Keep it Small” with Task Decomposition
Periodically I receive inquiries from people in the startup community who are exploring an idea or want an estimate on how expensive this particular idea may be to implement - as is common in the entrepreneurial community I’m happy to pay it forward (because I received help like this when I was just getting started too) and review a pitch deck, specification, or business plan and offer my advice if the person is someone I’ve interacted with online, in-person, or is referred through someone else I know.
Most of these pitches are doomed from the start. It’s not because the idea is terrible (although many often are) or because there’s some impassable barrier to market entry. It’s because the founder has insufficient skin in the game and thus, they’re not going to behave successfully. Why is that?
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.