I’ve managed to successfully wean myself from Instagram and Facebook, but I just can’t quit Twitter. No, I don’t stay because of the constant virtue signaling and politicking, but rather because of what I learn. For example, I’ve been in open source for nearly 20 years, and just this past week folks on Twitter taught me (or reminded me) of some important principles.
Open source is just that… open
Lost in all the recent debates over open source licensing is that pesky word: Open. I’ve kept my bearings pretty well in that fracas (I find the pseudo-open source licensing frustrating, counter-productive, and deceitful… other than that it’s great! :-), but lost my way in a tweet about China using open source to create closed systems of control.
SEE: 20 quick tips to make Linux networking easier (free PDF) (TechRepublic)
The Linux Foundation’s Lisa Caywood never lost sight of the importance of open source: “This is getting silly. First, ‘our best’–if it’s open source, by definition, it belongs to the global commons, not just ‘people like me’. Second, what percentage of committers on most projects are Chinese?” As she noted, not only have Chinese developers been active participants in open source projects but, even if they weren’t, open means open. We don’t get to pick and choose for whom it is open.
If we did, it wouldn’t be open source. As developers increase in importance to all kinds of companies, attracting them with truly open source becomes ever more important. Open source should be open.
Bless the packagers
Another Twitter lesson came courtesy of SADA Systems’ CTO Miles Ward. Having written about GitLab recently, I noted a complaint I’d heard that GitLab “simply packages and sells open source; that their IP is thin.” It’s a criticism that has been leveled at an array of companies, from Linux vendors Canonical and Red Hat to the public clouds today.
It fails to account for the tremendous value involved in making turning those open source projects into viable products that customers can easily use. As Ward said of GitLab, “[T]hey’re contributing upstream AND doing a heap of packaging work. 99% of customers just want the shortest route to value….” Obviously, that upstream commitment of code to projects is important, but so, too, is the packaging work that makes that open source code more accessible to developers.
This may be particularly true for complex infrastructure software. This has certainly been true for Red Hat. Back in 2006, Brian Stevens, then CTO at Red Hat, had this to say, “Red Hat’s model works because of the complexity of the technology we work with. An operating platform has a lot of moving parts, and customers are willing to pay to be insulated from that complexity.” Or, as BK Lau put it, “Plumbing at the end don’t make money, they are costs. Any easy way to get plumbing off development’s back is a win.”
Red Hat’s business model revolves around making complicated open source infrastructure technology easy for enterprises to consume, not unlike what the public clouds do today. Open source needs both upstream code and downstream ease-of-adoption. Both matter.
Finally, there’s the importance of an open, welcoming culture within open source. Open source projects have sometimes been guarded by prickly paragons of boorish behavior, unwelcoming to newbies. This has the perverse outcome of limiting the rise of developers within a project even as the importance of those developers grows.
As Redmonk’s James Governor declared at a recent conference (paraphrased by his colleague, Rachel Stephens),
We need to make open source communities and hacker culture more welcoming. The goal is to grow the community. To that end it is super unhelpful to alienate people (especially newcomers) by insulting them when they ask questions and try to contribute.
This also means that “We can’t grow the developer community without treating our women colleagues better,” he stressed. In addition, simply being kinder toward technology choices can pay dividends: “Our tendency to dunk on technology choices can have disparate impacts. (e.g., hating Ruby on Rails can disrespect the efforts of people learning via bootcamps, and that can mean discriminating people entering the industry from non-traditional backgrounds.”
In short, the more open our projects–in every sense of that word–the more likely we’ll be successful with open source. The stakes could not be higher.