Thoughts on the OSS dichotemy of customer consideration vs community consideration
Opened this issue · 0 comments
Inspired by: https://twitter.com/MaximRouiller/status/1449030617392418818?s=20
These are random notes from when I was just thinking out loud.
Very thought-provoking thread. Jotting down some raw notes here in case they're helpful, just based on what I've seen. As a consultant I've been in leading shops and seen clients that are a bit in the older days.
In 2017 I did a talk at .NET Fringe called "Casting a Wider .NET" -- It had an accompanying web site where I attempted to describe the different stages of OSS considerations in a business and how to move from one to the next. Old, stagnant site here: http://awider.net Video here: https://youtube.com/watch?v=jFDXNGFvcYg (be kind, I was pretty new to speaking on that sort of stage at that point. Smiling face with open mouth and cold sweat)
I think people on the consuming side fall into a few camps:
- FUD around OSS in general. Everything in house. Reinvents the wheel. Unfounded concerns, political hurdles.
- Only trusts Microsoft. The original consumer / mothership mentality that Microsoft worked hard to foster for a long time. It doesn't go away easily.
- Don't care where it comes from (MS or community) as long as it solves problems. Doesn't think much about the origins.
- Fully aware of OSS as consumers and appreciative users, but not considering their role.
- Participants in the ecosystem.
The concerns and constituencies share a little overlap but not much.
On the producer side, there are similarly:
- MS. Big tech shop, well funded, steward of the larger product. People working OSS as part of their job. Huge sway in the ecosystem. Risks of promotion-driven development and NIH syndrome.
- A small number of people who have been able to turn OSS or OSS-adjacent work into successful commercial pursuits.
- A large group of folks attempting to fill gaps in the ecosystem on top of their existing commitments. Labors of love and other intrinsic motivations. Lots of burnout, lots of emotion whenever things are made harder on them. Many important non-MS libraries within .NET fall into this camp.
On the consumer side, I think things are happy because a combination of the old MS culture (and I do believe it's in the past now) and consumer mindset means people are able to set expectations and consume these libraries without having to think about their supply chain and where they come from. Much like not everyone cares about eating at a sustainable farm-to-table restaurant (or cares to pay more in order to ensure that.)
On the producer side, I think we hear about a weak OSS ecosystem largely because Microsoft and the .NET Foundation have been unable to counter-balance the lack of maintainer support and participation in the ecosystem stemming from those old days. And as such, the producer side of the ecosystem -- particularly sustainability -- remains way weaker.
I think one of the struggles the .NET Foundation has is that it still naturally -- and I think from a quite well-intentioned place -- wants to focus on consumers, as is the Microsoft way. But what's happening is the OSS community, particularly maintainers, aren't seeing ROI and probably expected to be more of the focus of support than they have been. For example, the "maturity ladder" proposal for OSS projects was met with big resistance because it was focused on consumers with additional burden on maintainers and no additional support to go with it.
So, I'm actually considering re-launching AWider .NET with the express intention of filling this need -- surveying the community and its organizations, understanding how to move the needle to get more participation, creating impact maps and experiments around how to support a healthy ecosystem that exists alongside MS with sustainable support for maintainers. Materials on how to move your company along the journey of OSS consumption & participation, common resources and tooling that can benefit projects within the .NET Ecosystem, finding ways to bring lessons from the larger OSS community into the .NET OSS space.
This is of course, and overly simplified view as is any view that attempts to reconcile complex constituencies, but I figured I'd jot it down messily rather than try to make it perfect.
I think the way to remove the pushback is by helping consumers by enabling and supporting OSS projects from the ground up. If we want x thing out of open source, how can we influence those impacts in a way that is supportive and caring? If we want more participation, how can we attempt to influence individuals and institutions to engage there -- what can we do to remove any roadblocks and hesitation?
Impact maps are hugely helpful there. If you're not familiar with the term, the idea is a mind map from Goal --> Group/persona who can help --> how they could change their behavior to help reach the goal --> What we can do to influence that behavior change. I laid out a number of potential impact maps as part of my candidacy for the board, but I think the way the board/foundation is structured may not be conducive to thinking that way.
Lastly, the attempt to reconcile the MS desire to build things that help customers with the desire not to stifle the community.
When MS thinks about doing something, it would be awesome if it could consider whether something like that already exists in the community. If it exists, MS could choose to place trust in it -- support it, fund it, provide advice and resources for it. Think about the message that would send.
It's tough for MS to do this, and understandably so. I think Aaron Stannadard wrote a long time ago, accurately, that lots of Microsoft's success comes from controlling that entire process/stack/lifecycle and having the resources to make things that meet a very high quality bar. It's not in Microsoft's interest to cede this control, even if it could be in the community's interest. Microsoft is a business with paying customers.
Still, competition is good, and I think Microsoft considering other players in the ecosystem and supporting them with the express purpose of fostering that competition would be an incredible gesture of good faith. Instead of "welp, MS killed another project", it's "guess consumers are interested in this, so a rising tide lifts all boats."
If MS can help increase contributions to OSS by really communicating the benefits of it to customers, I think they'd find that quality bar is going to go way up as well. And it shows a respect for the maintainers, some of whom have a long memory and were doing this back when Microsoft was openly crapping on things.
I also think Microsoft can benefit internally and externally from committing -- as a business priority -- to build tooling that exists for OSS maintainers, and then use that tooling in the inner-source world. Bots for helping with repo organization/management, etc. etc. could probably benefit everyone. MS is missing a big opportunity to listen to the OSS community and build things alongside them in the open with the express intent of making maintainers' lives easier in a way that also gives MS an advantage internally.
Lastly, a thing I've been really thinking through is a "marketplace of needs" style setup. I re-did the NUnit docs to be an OSS static site using Docfx. I then created a process to lint the markdown files and check spelling as part of the CI for PRs. I then realized would benefit other projects, so I've contributed it to Marten and now am in the process of contributing it to Akka .NET.
Imagine if there was a place with a list of people who said "I'm good at x/y/z thing", and a list of projects who could say "oooh, good point, I could really use help with x/y/z thing" -- now imagine if all the extraordinary talent at MS was given some space to participate in an ecosystem like that. I feel like magic would happen. We go from "one project's needs / solutions" to a menu of ways to increase the quality of all projects, which benefits customers too. And, crucially, that system becomes a pull system where people are raising their hands, rather than a push system that attempts to achieve this from a top-down manner.