Community Management with Josh Heyer and Jon Ericson

I sat down with Josh Heyer (pronounced “higher”, sorry Josh) and Jon Ericson (both former Community Managers at Stack Overflow) about Community Management and Software teams on episode 4 of the Build Better Software Podcast.

Some of the talking points:

– Your software has a community even if you don’t realize it
– The “Who moved my cheese” parable is bullshit
– Software is a form of government (And has the same implications)
– A deep dive into “Stack Overflow Documentation”, (spoiler alert: it failed), where we talk about why it failed; and how those lessons apply more broadly.


LISTEN NOW

Does The .NET Foundation support Open Source or just Microsoft?

In case you missed it, Microsoft fucked over an open source project again.

Microsoft has lacked an OS level package manager since… well, since its inception. Chocolatey (the OS version of ‘nuget’ (pronounced nougat)) has existed in the community space as an OS-level package manager for a while; but that’s an open source project. Another developer took a chance and created an Open Source Windows Package Manager written in .NET (which is pretty cool), called “AppGet”. (Not sure if the similarity to ‘apt-get’ is intentional or not).

Anyway, AppGet (Github, Website) is pretty snazzy from a marketing perspective; and it hits all the right notes from an OSS perspective. As to why it ‘won’ over Chocolatey, I’m not sure it did; but since Microsoft chose to fuck them over instead of Chocolatey, we’ll go with AppGet winning*.

Microsoft decided to create its own Package Manager, and their team apparently decided to look at AppGet for ‘inspiration’. I’ll let the creator of AppGet take it from here:

When I showed it to my wife, the first thing she said was, “They Called it WinGet? are you serious!?” I didn’t even have to explain to her how the core mechanics, terminology, the manifest format and structure, even the package repository’s folder structure, are very inspired by AppGet.

If copying without attribution wasn’t bad enough (keep in mind, Oracle v. Google is being fought over the exact same issue: copying the structure of someone else’s API for commercial gain — though I won’t use this space to debate the merits of that argument, only to say that multi-billion dollar companies are fighting over this problem), Microsoft strung Keivan along for months after interviewing him, only to tell him on the eve of their announcement that he didn’t get the job, and oh, by the way they’re releasing their competitor package manager the next day.

He speaks of the impact that had:

What bothers me is how the whole thing was handled. The slow and dreadful communication speed. The total radio silence at the end. But the part that hurts the most was the announcement. AppGet, which is objectively where most ideas for WinGet came from, was only mentioned as another package manager that just happened to exist; While other package managers that WinGet shares very little with were mentioned and explained much more deliberately.

Since the publication of his medium post; Microsoft’s PM for WinGet, Andrew Clinick, released a milquetoast oblique ‘apology’ with an even more abstract title, “winget install learning“, where he says:

Last week we announced a package manager preview for Windows. Our goal is to provide a great product to our customers and community where everyone can contribute and receive recognition. The last thing that we want to do is alienate anyone in the process. That is why we are building it on GitHub in the open where everyone can contribute. Over the past couple of days we’ve listened and learned from our community and clearly we did not live up to this goal. More specifically, we failed to live up to this with Keivan and AppGet. This was the last thing that we wanted.

So, let’s review:

Microsoft decides in 2019 that it needs to have an OS level package manager. Microsoft sees several open-source projects that do just that; and they decide to meet with at least one of them, ostensibly to hire them. (this whole situation is even more fucked if Microsoft brought Keivan out to Redmond to brain-rape him (CW: language, sexual assault imagery)).

So, Andrew and his team meets with Keivan, and then ghosts Keivan for 6 months, while they produce Winget. They announce Winget, with no appreciable credit towards Keivan. After an initial uproar, the PM, Andrew Clinick, releases an embarrassingly obtuse and non-apologetic blog post, and the world goes on ticking.

Apparently, for Microsoft, that’s the end of it. They’ve done their bit, and called it a day.

If this were the end of it; it’d be pretty shitty behavior on the end of Microsoft’s Winget team, and their .NET Developer Division for enabling this behavior from Microsoft towards an open-source project; but… This isn’t the end of it. There are other players, which is what makes this even worse — and the latest in cautionary tales for .NET Open source developers: Microsoft has not changed their “Embrace, extend, extinguish” philosophy towards Open source.

The ‘other players’ I speak of is the .NET Foundation, and its Board of Directors.

How does the .NET Foundation fit in? I’m glad you asked. For the answer, I went back to Beth Massi’s History of the .NET Foundation to get the answer:

So, why did we need an open source software foundation? It was S. Somasegar (Soma) that pushed this idea to us. Soma was the Corporate Vice President of Developer Division at the time and our executive sponsor. Soma believed that the survival of the .NET ecosystem depended on the open source community and we needed a foundation to foster it. 
(…)
Soma knew that we needed to change the perception of Microsoft in the open source world and the creation of the .NET Foundation and the open sourcing of the platform would prove to be a strong step.

Beth goes on to write:

We also had projects from the community as well as our own that needed help; not just legal and licensing help but basic development services like code signing and CI/CD. We also had customers that needed to trust and rely on .NET. I was the community manager for the .NET platform team before any of our stuff was open source. And I was on the v-team that stood up the .NET Foundation itself. We were going through a culture change internally and our customers needed to also come with us.

(…)


Many of our customers expected all the software they used to come from Microsoft. It was a direct result of us creating a hugely successful closed source ecosystem. Microsoft also didn’t have the greatest track record with some of the open source projects we did release — where they were basically “thrown over the wall” and abandoned. The challenge was to make sure we didn’t lose trust — to make sure our customers understood that open sourcing .NET was not the end of the platform, but the beginning.

There are a few crucial points Beth makes here:

  • Microsoft had a bad reputation in the open source world
  • Microsoft would release open-source projects and abandon them
  • Microsoft needed to cultivate a reputation that it was open source friendly; by lending support to open source projects

And so they created the .NET Foundation. So let’s see what the .NET Foundation says it does, from its own front page:

Independent. Innovative. Always open source.
The .NET Foundation is an independent, non-profit organization established to support an innovative, commercially friendly, open-source ecosystem around the .NET platform.

“established to support an innovative, commercially friendly, open-source ecosystem around the .NET platform.” Surely,– I wonder what that means? In the context of a .NET open source project being extinguished by a corporation? Surely a .NET open source Windows Package Manager would qualify for the .NET Foundation’s mission, right?

Maybe not, so let’s dig deeper. The .NET Foundation ‘about‘ page says:

The .NET Foundation supports .NET open source in several ways:

Promote the broad spectrum of software available to .NET developers through NuGet.org, GitHub, and other venues.

Advocate for the needs of .NET open source developers in the community.

Evangelize the benefits of the .NET platform to a wider community of developers.

Promote the benefits of the open source model to developers already using .NET.

Offer administrative support for member projects.

Support .NET community events with sponsorship and content.

If we’re grading the .NET Foundation, they didn’t promote AppGet, they didn’t advocate for AppGet’s needs to Microsoft or the larger community, they didn’t ‘evangelize the benefit’s of the .NET Platform’, they didn’t promote the benefits of the open source model. They get a solid D-.

Incidentally, the actions the .NET Foundation does to ‘support’ .NET Open source doesn’t include any actions that would actually help these projects become commercially viable.

And here we get to the problem with the .NET Foundation.

The .NET Foundation says it exists to make open source commercially viable (for whom?), but in reality it exists to further Microsoft’s reputation in the open source space, not to help the community produce ‘commercially viable open source software’.

The AppGet problem is tailor-made for what the .NET Foundation claims is its purview; but when you pull the covers back, especially on Beth’s wonderful blog post about the history of the .NET Foundation, you realize that it was created to help show that Microsoft branded open source had the same viability as Microsoft products you buy.

Don’t believe me? Here’s Beth:

Many of our customers expected all the software they used to come from Microsoft. It was a direct result of us creating a hugely successful closed source ecosystem. Microsoft also didn’t have the greatest track record with some of the open source projects we did release — where they were basically “thrown over the wall” and abandoned. The challenge was to make sure we didn’t lose trust — to make sure our customers understood that open sourcing .NET was not the end of the platform, but the beginning.

Another telling line:

We were going through a culture change internally and our customers needed to also come with us.

So on the one hand, the .NET Foundation claims that it exists to further the community’s interests around open-source; when in reality — from its own history, it exists to further Microsoft’s interests in open source: To give their open source projects an air of legitimacy and corporate backing.

That’s harsh, but it’s true.

I’m not alone in thinking this; there’s a wonderful blog post on this very subject, titled “The New Rules for playing in Microsoft’s Open Source Sandbox“.

One of the many gems from the post:

Another example story on why you can build either something on Microsoft ecosystem or build something popular, but never do both.

Tweet by @Horusiath

Go ahead, read it, it’s worth your time. If you come back and you still believe Microsoft believes in open-source software, I have a bridge to sell you.

But, that’s not quite right, is it?

Microsoft *does* believe in open source software, and the .NET Foundation does believe in supporting .NET Open Source software, as long as it’s from or controlled by Microsoft.

I’ve repeatedly asked for comment from the board of directors for the .NET Foundation, only to receive radio silence — and I’m a dues paying member of the .NET Foundation!

If the .NET Foundation believes in supporting commercially viable open-source software built on .NET, then they have an obligation to step in with AppGet and at the very least release a statement condemning Microsoft’s actions. If they believe in supporting open-source software built on .NET, then it’s incumbent on them to continually promote it, not stay silent when their patron decides to steal a community project.

If Microsoft wants people to believe it’s changed, it’s actually got to change. There was a right way to go about releasing Winget; and Microsoft failed to do that. It’s pretty easy for a company with Microsoft’s valuation to do (disclosure: I am a Microsoft shareholder): Buy AppGet from Keivan. You don’t even have to use it. But buy it. Or, pay Keivan for his insights and work that you used in producing Winget. A solid one-day consulting fee would be $100K.

If the .NET Foundation wants the .NET community to believe it stands with us, then the .NET Foundation needs to step up and speak out against these highly corrosive actions that its patron takes. .NET Open source will never be commercially viable if big corporations like Microsoft feel free to steal the community’s work without paying for it.

It’s not about the process

“If you follow Scrum, you’ll deliver better software”

“If you do TDD, you’ll deliver better software”

Both of those statements may be true, but they’re unhelpful at their core.

For one thing, the person speaking them generally has survivorship bias; it worked for them so it should work for you too, QED.

Besides the bias inherent in that statement, they also tend to ignore that the ample evidence around us that not all teams are successful with scrum, and not all teams are successful with TDD.

But let’s flip that statement around.

Is the process responsible for your success?

the process can fail you, and you can fail. Those are independent variables; and though some processes do tend towards helping teams fall in the pit of success, The process can’t guarantee an outcome, and blind reliance on a process is a sure path towards failure.

The reason why the robots haven’t taken our jobs is that Software Development is, at its core, about turning human desires into an automated and useful system.

It’s that human aspect that we try to create processes to counteract or channel. The human aspect is why we make mistakes when we’re developing code; and why TDD can help. The human aspect is why double-entry bookkeeping is the accepted method for accounting. The human aspect is why software is so darned useful in the first place. It was made for us.

Before you chide a process, or point towards a process for your success, remember that it started with humans. It started with you and your team. You’re the success story, not the process.

P.S., I started a new podcast that is centered around helping software leaders enable their team to build better software. I recently spoke with Ben Mosior about Wardley Mapping, a technique for contexualizing your team, your business, or your software stack to better understand the landscape. It’s hard to think strategically if you can’t model where you’re at, and Wardley Mapping helps with that. Check out the episode here.

The Build Better Software Podcast

If you’ve been a member of my mailing list for a while (that are later republished to this blog), you’ll notice a pattern that the emails are mostly short missives on viewpoints, strategies, or techniques to help teams double their productivity.

They aren’t in depth, and they aren’t meant to be — the ‘how’ is elsewhere, because email is the wrong medium for that.

While I’m putting together the TDD course (Which gets into the tactical ‘how’ behind TDD), I’m finding myself wanting to refer to strategies and techniques that I haven’t fully explained; and that I can’t do justice to in an email. I also want to give voices to these lesser known techniques and strategies, to help software leaders enable their teams to build better software.

To that end, I started a podcast focused on topics that software leaders would find important but may not know about. Because naming is hard, I called it the “Build Better Software” podcast, and you can find it at https://www.buildbettersoftware.fm.

It’ll be a mostly weekly show (I am vacationing here in a few weeks, so chances are I’ll miss a week or two) where I either interview an expert in a given practice and we dive deep into how that practice can help software leaders (or not!) and contextualize these things we call ‘best practices’ into a digestible form and dive into them. Are they really best practices? Do they fit your usecase, team, context, business, and ability?

I hope to answer those questions in this podcast.

The first episode is on Wardley Mapping; a technique that can help you and your team contextualize your work; which is critically important in producing the right software, and the right time, for the right user.

If you have any topics you’d like explored, let me know in the comments. I’d love to explore them and share the outcome with you.