Evidently We're Not Cool Enough

I recently was driving a lot, and so I caught up on some missed episodes of Security Now! and it turns out that someone else found the same kind of bug that Lucas and I discovered and made a whole attack scenario out of it.

Now, Lucas and I explored this and Lucas went so far as to build a really cool and complex system out of this concept that we use at Mog.com to serve adds intelligently. If you look at mog.com ads, you'll see that we use a variant of the technique that has been demonstrated to perform cross-domain ajax.

But even though we had a working demonstration, there is no credit or recognition. In fact, security professionals shouted us down with a resounding "DUH!" Bummer, eh? I know someone could argue that we didn't show how to attack without local domain permissions, but that's because we deliberately left it out. We obviously understood it, because we've got existing work using it. :)

Double Jeopardy and Ruby on Rails

Recently my co-worker Lucas made a big to-do about Rails and the culture surrounding Core and the way that they do patches. Unsurprisingly, he got a lot of pushback for that. At first glance, it might seem like Lucas is being bitter about failing to push a patch through. But when we talked on the #caboose IRC channel about the subject, there was a surprising amount of agreement.

For people unfamiliar with the culture in Rails, it might even seem hypocritical. I mean, Ruby and Rails both alter syntax to encourage and discourage behavior. Why do we tolerate it from Ruby but lament it from Rails? I think it has to do with the different cultures surrounding Ruby and surrounding Rails.

In Ruby, subtle cues in the language syntax are meant to gradually discourage users from using specific features. For example,

class Thing
 attr_accessor :ivar

 def pretty
   self.ivar
 end

 def ugly
   @ivar
 end
end

The Ruby community considers the @ glyph to be ugly, and in general it's discouraged to touch instance variables directly, since they are created on the fly. Using the attr_* meta-methods is far preferred. This is a subtle but noticable tug that exists throughout ruby code: use ugly and intrusive glyphs to highlight discouraged behavior. And in general, most Ruby developers like this approach. It's clear and unintrusive, and it highlights danger without preventing hackers from doing what they love to do. And when they come back from this hacking with suggestions, Matz and his cadre have the final say in how Ruby evolves, but his community is surprisingly open to suggestions and the RCR process is extremely transparent.

Rails has a similar philosophy with "Opinionated Software." To pull from DHH's post on Syntactic Vinegar, they discourage users from working with the old non-block-oriented form generation code by turning what used to be this:

<%= start_form_tag :action => "create" %>
My pretty form!
<%= end_form_tag %>

into either a block form, or this:

<%= form_tag :action => "create" %>
My pretty form!
</form>

It's interesting to see that the alternative rails way is much uglier (lacking symmetry) and harder to read. And in this case, I agree that the new block form is much nicer, and in general people should stick to the beaten path when it comes to this issue. So far, the similarity is pretty clear, but where it ends is where the Rails culture begins to accept feedback. Like Ruby, Rails has DHH and a small cadre of developers with final-say. But unlike Ruby, the Rails process is hardly open at all–a few brief responses on a Trac is all you're likely to get.

It's frustrating, because every Rails developer doing a non-trivial website can tell you Rails is all about customization, modification, and new development. We make lots of modifications just to make our ideas possible to develop and maintain. Rails doesn't really reward this, indeed it discourages it. That's okay, because we understand that no framework can be all things to all people, and many times the Rails way is in fact the best way to go about doing something. It's still better than the competition, after all. But when we come back to the community to try and relate our techniques, experiences, and modifications, the process often feels like a job interview.

It seems strange to me to inflict this double jeopardy on the most experienced and valuable users of your framework. Nearly every Rails developer I know can point to a patch idea they submitted that was rejected, and later implemented anyways in a different fashion (in some cases less effectively). This is sharply at odds with the rest of the Open Source World, where projects tend to be very open and friendly to contribution. Many fans of rails listen to complaints of shortcomings and respond with the Open Source rallying cry, "Just fix it!" But part of that fixing process is contributing code back to the codebase, and many competent developers who had sound ideas have been denied because of Rails's "Opinionated" nature.

In the end, the key difference between the philosophy of Rails and Ruby is that Ruby says, "This is Pretty" and Rails says "This is Right." The Rails Core team–as a whole–is opaque, intimidating, and insular. Often patches are rejected with minimal reason and then added in later anyways, with no originating credit. They lack the openness and attribution that makes people want to work on open source projects. Rails exists because it's better than the competition, which is the best place to be, but it doesn't foster the kind of happiness and delight that a more open project like Ruby has.

Does that even matter? Look at Linux and ask yourself, "If people didn't want to commit to Linux, would it still be around, or in the position it enjoys today?"