Thursday, July 31, 2014

The Bizarre Bazaar: Who Owns Express.js?

A GitHub Drama


After abandoning Node.js for Go, TJ Holowaychuk apparently made his separation official by selling off the branding and official GitHub "ownership" of his Express framework to StrongLoop, a Node.js company whose projects include software services, consulting services, support, and free software. (StrongLoop's CEO, by the way, is no stranger to the concept of businesses based on free software, having previously sold his startup Makara to Red Hat and developed Red Hat's OpenShift product - Red Hat being the company which pioneered open source business models.)

As an aside, I'm often disturbed by how many things GitHub is these days.


The latest Node.js drama undermines my tweeted theory, because much of the drama unfolds on GitHub. So maybe GitHub's a Twitter which used to be an emacs?

Anyway, here's the history. If my retelling fails at fairness, apologies to all involved.

First, StrongLoop announced the sponsorship on its blog. A major Express contributor immediately filed an issue on GitHub: "This repo needs to belong in the expressjs org." The discussion that unfolded there is interesting (although currently locked), but here's a summary: Holowaychuk transferred ownership to StrongLoop without either asking or informing the Express community beforehand. StrongLoop's been committed to Node.js for a good while now, and hopes to support Express with documentation and continued development. However, the Express community may have taken over for Holowaychuk some time ago, so there's some contention over whether or not the "ownership" of the project was legitimately his to transfer in the first place.

An angry blog post argues that it was not:

When TJ Holowaychuk lost interest in maintaining Express, he did the right thing (for a change) by letting others take over and keep it going. In open source, that meant the project was no longer his, even if it was located under his GitHub account – a common practice when other people take over a project.

Keeping a project under its original URL is a nice way to maintain continuity and give credit to the original author. It does not give that person the right to take control back without permission, especially not for the sole purpose of selling it to someone else...

What makes this particular move worse, is the fact that ownership was transferred to a company that directly monetizes Express by selling both professional services and products built on top of it. It gives StrongLoop an unfair advantage over other companies providing node services by putting them in control of a key community asset. It creates a potential conflict of interest between promoting Express vs. their commercial framework LoopBack (which is built on top of Express).

This move only benefits StrongLoop and TJ Holowaychuk, and disadvantages the people who matter the most – the project active maintainers and its community.


Holowaychuk responded with a blog post of its own, pointing out that he had communicated with Doug Wilson of the Express community, asking Wilson if he'd like some of the proceeds of the deal:

My intent was to share said compensation with Douglas since he has been the primary maintainer on Express lately. I signalled that intent by emailing him...

I don't want to wade into the drama here, which is why I've made an effort here to be dispassionate and objective. I'm totally happy to let that shake out however it shakes out. But I have to admit that I think there's a really interesting question at the heart of all this: who owned the Express web framework? Was it really Holowaychuk's to sell?

I find this question interesting because it reminds me of a totally wrong theory I cooked up recently: that being free is what ruined the Ruby web framework Rails.

Totally Wrong Theory: Being Free Ruined Rails


I've previously argued that the Rails/Merb merge was a mistake, and that Rails went off the rails. I came up with my new, totally wrong theory when I was trying to figure out how the Rails/Merb merge happened in the first place.

Before I get into it, I want to point out that one of the major flaws in my theory here is that Rails isn't actually ruined. As I said, the theory is a totally wrong theory (and being totally wrong is obviously another one of its flaws). But I want to explore the idea to illustrate some of the flaws in the purist, old-school definitions of open source software. Because I don't think that theory is correct, either.

That theory comes from Eric Raymond's The Cathedral and the Bazaar, which provides a great statement of the classic concept of what open source is, and what open source means. This essay, and the book it later became, first articulated the idea that "with enough eyeballs, all bugs are shallow," and laid out 19 rules of open source development. For example, "the next best thing to having good ideas is recognizing good ideas from your users. Sometimes the latter is better." Or, "release early. Release often. And listen to your customers."

The Cathedral represents a software development model where developers build code in private and release it in public. The Bazaar represents a model where all development occurs in public. Raymond argues for the Bazaar in favor of the Cathedral. I don't know how development worked in Express, or how it will proceed now, but Rails uses a hybrid model, where the majority of development occurs in public, yet certain decisions happen in private.

Many other projects use this model as well. (Obviously, in the case of Express, the decision to sell sponsorship occurred in private.)

The Rails/Merb merge is one example of a major decision which occurred in private. There was no public debate, just a sudden announcement, with a big thank you to the Merb team for all the free help that would get Rails 2 to Rails 3. But free help isn't always free.

37Signals (now Basecamp) have long advocated turning down unnecessary feature requests, and Rails creator David Heinemeier Hansson took the idea to absurd lengths with his description of Rails as an "omakase" framework. But one explanation for the Rails/Merb merge is that EngineYard said "we'll pay for Rails 3 to happen, as long as Rails 3 is also Merb 2," and members of Rails core forgot their own advice about turning down unnecessary feature requests because, for once, the unnecessary feature requests came along with the offer of (unnecessary) free work.

To be clear, the feature requests, and the free work to support them, were unnecessary in my opinion, but not in the opinion of the people who made the merge happen. I'm going to make an attempt to be objective regarding Express, but when it comes to Rails, that train has already sailed. It's my belief that the Rails/Merb merge brought Rails an incomplete but ambitious modularity it didn't actually need, and that there's an inherent irony here, because Mr. Hansson vigorously and scornfully opposed adding a different kind of modularity to Rails apps: stuff like moving business logic out of Rails models and into simple Ruby objects, moving application logic out of Rails entirely and treating it as a library instead of a framework, and wrapping Rails's ActionMailer system in simpler API calls like Email.send.

Good Modularity and Bad Modularity


The general theme: how to unfuck a monorail. Many Rails developers wrestle with this theme, but Mr. Hansson seems (in my opinion) to dismiss it categorically and without any significant consideration. (Indeed, so many Rails developers wrestle with this issue that I think it's fair to call it a crucial moment in the lifecycle of most Rails apps.)

Some of these things are a lot easier to do because of the Rails/Merb merge, yet it's interesting to contrast Mr. Hansson's hostility to these ideas with his embrace of the merge. On the one hand, we saw claims of a powerful modularity that either failed to materialize or which proved useful to only a few people.



On the flip side, Rails's creator seemed pretty contemptuous of people who created simpler, more practical forms of modularization to suit the needs of their individual applications. It's a fascinating contradiction, from the developer who once lambasted "architecture astronauts," to attack pragmatic modularization with very immediate causes, while championing an abstract modularity with less obvious usefulness.

I think this was an error in judgement, and I think it happened because the work seemingly came for free. Because why else would a team famous for ignoring feature requests happily embrace an incredibly ambitious set of feature requests?

Managing open source frameworks takes time. Writing code takes time; discussing pull requests takes time; and running a private chat room for your "open source" project takes time.

To unpack that last statement, gaining access to the private Rails core Campfire is a key step in becoming a member of Rails core:

Yehuda gave me access to control the LightHouse tickets and to the Rails CampFire...The fact that I was invited to be a part of the Rails Core Team really surprised me. It was unexpected until I read Yehuda in CampFire saying that the guys with commit access should join the core team after the release of Rails 3 and David was OK with that.

Here's where Rails operates as a hybrid between the Cathedral and the Bazaar. Its core team's private Campfire chat functions as a Cathedral, but its GitHub activity functions as a Bazaar.

The Bizarre Bazaar


The Cathedral and the Bazaar argues that the Bazaar is superior because no one person is smarter than a community of smart people, and because nobody can craft a One True Design™ which is better suited to a problem space than the design which will emerge if you allow lots of people to work on the problem.

This is obviously very different from the "omakase" philosophy of Rails. And there are benefits to that philosophy. When Rails first came on the scene, it seemed like an Apple product - impeccably designed, shaped by the kind of singular focus no community could ever achieve. No community would ever decide in aggregate to shape a project around REST in 2006, or to unilaterally replace JavaScript with CoffeeScript. Communities typically suck at boldness, as well as beautiful user experience, and one of Rails's greatest innovations was treating the developer's user experience as one of the most important aspects of its design.

Yet the "omakase" philosophy also created a community which operates on the foundation of an unspoken shared disregard for the community's alleged leadership. The sign of an experienced Rails developer is a weird duality; a skilled Rails dev knows the recommendations of Rails core, and ignores or contradicts most of them. As Steve Klabnik said, Rails really has two default stacks, the "omakase" stack and the "Prime" stack, which could also be described as the official stack and the stack which is the default for everybody except 37Signals and utter newbies. There is something just deeply, dementedly messed-up about a community where following best practices, or believing that the documentation is correct, are both sure signs of cluelessness.

Rails is not the only open source project to feature this half-Cathedral, half-Bazaar hybrid. (You could call it a bizarre Bazaar.) Ember works in a similar way, and Cognitect's transit-ruby project features the following disclaimer in their README:

This library is open source, developed internally by Cognitect. We welcome discussions of potential problems and enhancement suggestions on the transit-format mailing list. Issues can be filed using GitHub issues for this project. Because transit is incorporated into products and client projects, we prefer to do development internally and are not accepting pull requests or patches.

(This disclaimer, of course, did not prevent people from filing pull requests anyway, one of which was unofficially accepted.)

Sidekiq & Sidekiq Pro


I believe 37Signals and EngineYard both have funded some of Rails's development, and that they're far from alone in this. I know ENTP did the same when I worked for them, and I believe that's also true of Thoughtbot, Platformatec, several other companies, and of course a staggering number of independent individuals. I'm certain Twitter directly funded some of the work on Apache Mesos, and that Google indirectly funded it as well by contributing to Berkeley's AMP Lab, where Mesos originated. While "open source" was the opposite of corporate development when the idea first swept the world, today most successful open source projects have seen a company, or several companies, pay somebody to work on the project, even though the project then gives the work away for free.

It's an amazing evolution in the economics of software, and something I think everybody should be grateful for.

However, I know of an alternate model, and I have to wonder how Rails might have handled the Merb merge differently, if it had been using this model instead. This is the Sidekiq and Sidekiq Pro model.

In his blog post How to Make $100K in OSS by Working Hard, Mike Perham wrote:

My Sidekiq project isn’t just about building the best background processing framework for Ruby, it’s also a venue for me to experiment with ways to make open source software financially sustainable for the developers who work on it hundreds of hours each year (e.g. me)...

When Sidekiq was first released in Feb 2012, I offered a commercial license for $50. Don’t like Sidekiq’s standard LGPL license? Upgrade to a commercial license. In nine months of selling commercial licenses, I sold 33 for $1,650...

In October last year I announced a big change: I would sell additional functionality in the form of an add-on Rubygem. Sidekiq Pro would cost $500 per company and add several complex but useful features not in the Sidekiq gem...

In the last year selling Sidekiq Pro, I sold about 140 copies for $70,000. Assuming I’ve spent 700 hours on Sidekiq so far, that’s $100/hr. Success! Sales have actually notched up as Sidekiq has become more popular and pervasive: my current sales rate appears to be about $100,000/yr.


If I recall correctly, when he wrote this blog post, Perham was also working full-time as Director of Infrastructure at an ecommerce startup. His blog now lists his job as Founder and CEO of Contributed Systems, whose first product family consists of Sidekiq and Sidekiq Pro. Perham seems to have discovered a really effective model for funding open source software.

What if Rails had used this model? I like to think there's an alternate universe where this happened; where 37Signals gave away Rails for free, and charged a licensing fee for an expanded, more powerful version called Rails Pro.

Rails & Rails Pro


I like to imagine that in this alternate universe, when people wrestled with the paralyzing monorail stage of the Rails app lifecycle, Mr. Hansson and the other members of the Rails core team would have had no choice but to listen to their users, because their business depended on it. I also like to imagine that in this alternate universe, a Merb merge would not have been possible. The financial incentives to think carefully before accepting feature requests, even when they arrive in the form of code, would have been stronger.


But this business model raises a whole bunch of questions, because so many people and companies contributed so much time and effort to make Rails in the first place. Would they have done the same, in this alternate universe? It's one thing when you're contributing to a project "everybody" owns, and another when you're contributing to somebody else's business. (Sidekiq certainly sees a lot of contributions, but Perham does most of the work, and I can't currently peek at the contrib graph for Sidekiq Pro.)

And consider: What happens if Mike Perham wants to sell Sidekiq and Sidekiq Pro? For that matter, what happens if 37Signals wants to sell their interest in Rails? And what if Express had been using this business model? Can you hand off your semi-open-source, semi-commercial project for somebody else to run?

From the "About Us" section on the home page for Mike Perham's company Contributed Systems:

We believe that open source software is the right way to build systems; building products on top of an open source core means the software will be maintained and supported for years to come.

Contributed Systems is a play on the computer science term "distributed systems" and the fact that we allow anyone to contribute to our software.


Sidekiq's popular for a reason: it's really good. And if Sidekiq Pro accepts contributions just like Sidekiq does, then it's neither really open source nor closed source, but more like "gated community source." (Because it's a Ruby gem, so my guess is that it is open source for those who have access to it, but you have to pay to get that access in the first place.)

There's an enormous mess of contradictions here. Software development is basically the only industry making money right now in the entire United States. And yet its foundation is this basically communist idea that everybody will contribute to the greater good. The idea that you can sell sponsorship and/or ownership of a project, as with TJ Holowaychuk and StrongLoop, really exposes these contradictions.

Law Is Hard, Let's Go Hacking


Perham's "gated community" model might be the best approach. Most open source licenses prefer to avoid these issues by entirely disavowing any and all responsibility. It's simpler, but I doubt it's as sustainable. Here's the MIT Public License:

Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.


Translation: "no money changes hands, and you can do anything you want as long as you acknowledge authorship, but we take no responsibility at all for anything which happens, so don't ask us for shit."

I am not a lawyer. If you're a lawyer reading this, I have a question for you: would disavowing any and all warranties still even be possible under the law if money had changed hands?

In a similar vein, I don't think any true Bazaar exists, in the sense of Eric Raymond's metaphor, because it's customary in open source projects to yield final decision-making power to whoever started the project, and to refer to that person as the project's Benevolent Dictator for Life. (If Holowaychuk had any real right to sell Express, this might be where it came from.) That one individual person's final decision-making process is inherently closed, and could only be truly open if we all developed the power of telepathy. I think this "BDFL" custom exists because it's much easier to skirt the issue of the contributors' social contract than it is to define anything more specific.

(Pirate Party founder Rick Falkvinge talks about this extensively in his book Swarmwise, which is essentially about how to use the development model of open source software for political purposes instead. He makes the point that adding a formal voting process to a chaotic, ad hoc organization is most likely to alienate the people who would otherwise become the organization's most productive members, because highly productive contributors are not typically fans of overly bureaucratic process.)

Communist Capitalism or Capitalist Communism?


The open source movement dates back as far as the late 1970s, although at that time it was known as the free software movement, and that is actually a different thing. Whereas the free software movement saw software transparency as a requirement for a free society, open source seeks to fit the superior utility of open development practices into a business framework.

The "open source" label was created at a strategy session held on February 3rd, 1998 in Palo Alto, California, shortly after the announcement of the release of the Netscape source code. The strategy session grew from a realization that the attention around the Netscape announcement had created an opportunity to educate and advocate for the superiority of an open development process...

The conferees also believed that it would be useful to have a single label that identified this approach and distinguished it from the philosophically- and politically-focused label "free software."


Open source projects very often use a communist methodology for capitalist purposes. There are times when this duality is tremendously entertaining; for instance, any time a Linux sysdamin tells you "Communism doesn't work," you get a free joke. Likewise, you get a free joke any time somebody tells you that Linux proves all software should be open source, and the joke is the user interface for Blender, an open source 3D graphics and animation package with notoriously incompetent UX. I think it's extremely likely that the only way to produce good software is to balance capitalist interests against a communist methodology, and if I'm correct about that, it would certainly qualify as one of the many reasons software is inherently hard to get right. The inherent tension between these two forces is tremendous. The drama around Express's transfer of ownership springs from that.

I'd love to give you a pat answer to the question of who owns Express.js, but I think it's a big question.


Update: Mike Perham wrote me to say that his customers can contribute to Sidekiq Pro, and that 5-10 customers have, although he has to own the copyright, to keep the publishing/licensing issues from being insane.

Sunday, July 6, 2014

Why And How Bayhem Works