Open Source is hard.
Security is hard
There's been lots of articles about the recent OpenSSL "Heartbleed" bug. You can spend a day reading all the technical analysis, but one headline that stood out to me was "OpenSSL shows big problem with open source; underfunded, understaffed." A fundamental part of the fabric of The Internet Itself is mostly just one person plus a bunch of volunteers.
"The fascinating, mind-boggling fact here is that you have this critical piece of network infrastructure that really runs a large part of the Internet, and there’s basically one guy working on it full time."
Moreover, we don't sing contributor's praises for their hard work and success while their software work, instead we wait until a single line (albeit one of the more important lines) fails to live up to expectations. Darn that free stuff, mostly working, and powering our connected global network.
Open Source is largely a thankless job. Sometimes in the Microsoft .NET community, it feels more futile because it's often hard to find volunteers. Many folks use the default stuff, or whatever ships with Visual Studio. With Rails or Node, while they have corporate backing, there's a sense that the projects are community driven. The reality is in-between, but with open source projects built on the Microsoft stack volunteers may say "we'll just use whatever the ship."
There's anger around past actions by Microsoft, but as I've said publicly before, they've come a LONG way. I will keep pushing open source at Microsoft until I think I'm done pushing and can push no more. There's a seismic shift going on inside. Mistakes get made, but it's moving in the right direction. Everyone is learning.
Visibility is hard
Jeremy Miller's team recently stopped active development on the "FubuMVC" open source .NET framework. In his exit blog post, the question of the viability of .NET open source comes up:
"Setting aside the very real question of whether or not OSS in .Net is a viable proposition (it's largely not, no matter how hoarse Scott Hanselman makes himself trying to say otherwise), FubuMVC failed because we — and probably mostly me because I had the most visibility by far — did not do enough to market ourselves and build community through blog posts, documentation, and conference speaking."
It's very true that in a large way visibility drives viability for many open source projects. Jeremy's retrospective is excellent and you should read it.
I think it's harder to bootstrap a large framework project that is an are alternatives to existing large frameworks because for many, it's easier to use the default. Frameworks like FubuMVC, OpenRasta, ServiceStack, Nancy and others all "reimagine the default." They are large opinionated (in a the best way) frameworks that challenge the status quo. But it's much more difficult to cultivate support for a large framework than it is a smaller library like Humanizer or JSON.NET.
Still, without these projects, we'd all still be using the defaults and wouldn't be exploring new ideas and pushing limits as a community like the FAKE F# build system, or Chocolatey, or Boxstarter.
Microsoft can better support OSS projects not just with licenses and money, but with visibility. I'd propose dedicate Open Source tracks at all Microsoft conferences with speaking slots for open source community members. DotNetConf is a start, but we can go bigger.
Organizing is hard
OWIN is an example of a small, but extremely important project that affects the .NET world that is struggling with organization. Getting it right is going to be important for the future. There's a small, but influential group of community members that having been trying for months to find middle ground and build consensus around a technical issue.
ASP.NET Web API and SignalR both build on top of an open source project called OWIN (Open Web Interface in .NET) that aims to decouple servers, frameworks, and middleware from each other.
There's an issue open over on GitHub about what may seems like an obscure but important point about OWIN. The OWIN specification doesn't include an interface called IAppBuilder, but IAppBuilder is used by default in most Microsoft examples. Can the underlying OWIN framework remain neutral? The issue is a long one, and goes off on a few tangents. It's a complex problem that perhaps 20 people fully understand.
Scott Koon worked hard on a Governance document for OWIN and hasn't seen any forward motion. He vented his frustration on Twitter, rightfully so. Under the often-used "Lazy Consensus" technique, if folks are silent or don't reply in 72 hours, that is effectively consent and can change the direction of a project. Active involvement matters.
The fun part of open source is the pull requests and writing code, but before the code building, there's the consensus building. Ownership is the most contentious part of this process. Ownership means control; control over direction. The key to finding control and working through ownership issues is by thoroughly understanding everyone's differing goals and finding a shared vision that the community can rally around, then move forward.
This sausage making process is tedious, messy, but necessary. These discussions are as much a part of OSS as the code is. It takes equal parts patience and pushing.
Getting involved is hard
I get dozens of emails every week that all ask "how can I get involved in open source?" Everyone assumes my answer will be "write code" or "send a pull request," or sometimes, "help write documentation."
In fact, that's not all you can do. What you can do is read. Absorb. Understand. Be welcoming, inclusive, and kind. Offer thoughtful analysis and ask questions. Avoid hyperbole and inflammatory language. Show code examples when commenting on issues. Be helpful.
Your blog posts are the engine of community, your open source commits, documentation, promotion, samples, talks, gists are important. But getting involved in open source doesn't always mean "fork a project and send a giant pull request with your worldview." Sometimes it's the important but unglamorous work of writing a governance document, organizing a conference call, or thoroughly reading a giant Github issue thread before asking a question.
Why do we do this? It's not for the glamour or the money. It's because we are Builders. I encourage you all to get involved. There's lots to be done.
* photo by Sweet Chili Arts, used under CC
Sponsor: Big thanks to Novalys for sponsoring the blog feed this week! Check out their security solution thatcombines authentication and user permissions. Secure access to features and data in most applications & architectures (.NET, Java, C++, SaaS, Web SSO, Cloud...). Try Visual Guard for FREE.
Hosting By
