Sarah Allen of Blazing Cloud is a true open source insider. In this episode of Cloud Out Loud, she and Matt discuss the Ruby Ecosystem and its effect on programmer happiness. Don’t miss her incisive speculations about why our favorite language and the people who use it are so disruptive. Matt: Sarah, why don’t you introduce yourself?
Sarah: I lead a consulting company in San Francisco called \"Blazing Cloud\":http://blazingcloud.net/, where we create Ruby on Rails web applications and mobile applications and all that fancy front-end Javascript stuff that people like to see on the web these days. I also lead a nonprofit called \"Rails Bridge\":http://railsbridge.org/, which seeks to broaden the community and diversify it and makes it clear how to go from being an aspiring developer to being an open source contributor.
Matt: How does this Ruby on Rails ecosystem differ from other communities that you’ve been a part of in tech?
Sarah: The Ruby ecosystem has a few things that I haven’t really seen combined in this way before. There’s open source, which is becoming more and more a part of business. There’s a thriving business climate, there are a lot of hot jobs available, there are a lot of companies starting to use Ruby. There’s a thriving community. When I was developing desktop apps, I don’t think I would ever have said that there was a “C community.” I think that we’ve seen business booms and downturns, and during the last couple booms, I saw a lot of contraction--people got really proprietary about their ideas and their innovations and people felt like, “I’m going to be successful because of my secrets.” We’re seeing something very different now.
Matt: You once said to me, “Ruby just makes you happy.” I’m curious—is this a part of why this feels like a more dynamic and active community of developers and engineers?
Sarah: That’s part of the driver of it. Ruby makes people want to create stuff that is maybe a little peripheral to the core business value. There’s a new value system that says, “I ought to be happy about my work. I ought to take a little extra time to make toys that I enjoy using, and I ought to share those toys with my friends because I want my friends to be happy.” When people really enjoy working with something and making something and being a part of something, they do it more.
I think that people refer a lot to \"Matz\":http://translate.google.com/translate?u=http://www.rubyist.net/~matz/&langpair=ja|en&hl=en&ie=UTF-8&oe=UTF-8&prev=/language_tools creating Ruby to make programmers happy. He wanted to address the design of the user interface. He wanted to think about how people use it and make them productive, and he had a lot of foresight in stating that.
I also think there are some attributes, technically, that make it easy to mix and match components. The way that the language is implemented--as a dynamic language with an object-oriented paradigm that stems from Smalltalk--makes it easier to introduce new components that act seamlessly like old components. The last thing is that because the community is vigilant about testing, and there’s tremendous support for testing, it means that you can just try new things.
Matt: there seems to be a velocity in this ecosystem in which things go from zero-to-deployed-everywhere in a matter of months. For example, Unicorn; I never heard of it until summer 2010, and now it’s winter, and most of the apps we see coming onto Engine Yard AppCloud are in Unicorn. Can you talk a little bit about the velocity we’re seeing in this ecosystem?
Sarah: A number of things contribute to that velocity. One of them is this emphasis on testing—people are free to experiment because they have a safety net. There is a pride people take in showing off what they do. Reputations in the community are built by producing open-source software, so there’s an evangelism that happens in the community. I have a friend who says that Ruby is a language for extroverts.
Matt: Do you think anything is sacrificed by having such high velocity? Our engineers talk a lot about CI and the false notion that a QA team is the be-all-end-all of finding a problem. Could you talk a little bit about that and what the philosophy is like, and how that differs from more traditional engineering groups?
Sarah: I think we’re still learning how to do \"agile development\":http://en.wikipedia.org/wiki/Agilesoftwaredevelopment in such a way that you have the traditional notions of reliability, the five nines, all of that stuff. What a lot of us are noticing is that when we worked in a climate where you had made commitments, and you had run test plans, and you had three-- month beta cycles, you still shipped with bugs. And you still had SLAs that stated how quickly you had to respond to customers because stuff happened in the field. What we’re learning is that there are new ways to develop software that can be just as reliable as the old-fashioned ways, but through different processes we can get it out there faster. The reason I say we’re still learning is that there have been new innovations in the last few years around Continuous Deployment. For example, \"Eric Ries\":http://www.startuplessonslearned.com/2009/06/why-continuous-deployment.html has been very outspoken about what he calls an “immune system” around your deployment, where if anything goes wrong you can roll back immediately, and you have areas around your website that take the brunt of things first.
Matt: Is there something in Ruby that makes it a kind of digital antibiotic?
Sarah: The attributes of Ruby in terms of it being a dynamic language really play into that. I think that Dynamic languages are really effective in this kind of agile creation and responsiveness. However, I think there are other languages that could probably work this way, for example, Smalltalk proponents would say that that language is ideal in this environment. But what we have with Ruby is not only the language properties themselves, but the thousands and thousands of \"gems\":http://rubygems.org/ that are almost entirely open source. We have a fabulous package system, version control, things like \"Github\":https://github.com/ that by default when you share code you make it public. By default you have read-me’s that are published on the web and are searchable by Google. By default, you have all of these mechanisms that let you publish, collaborate, and make things available.
I was teaching a class a couple months ago and talking about the importance of gems, and how to determine if something’s a good gem. These days you can’t rely on something having a staid, well-known name to know it’s reliable; like \"Unicorn\":http://unicorn.bogomips.org/—how would you know by hearing that name that it’s something you ought to deploy? Or something could be created by a fictitious person, like why the lucky stiff, and still it is great code that you should deploy.
Matt: Who is \"why the lucky stiff\":http://en.wikipedia.org/wiki/Whythelucky_stiff?
Sarah: He was a very prolific Ruby programmer, who built \"35 popularly used libraries\":https://github.com/whymirror. He did serious things like \"XML parsers\":https://github.com/hpricot/hpricot, and whimsical things like creating \"environments for kids to learn programming\":http://hackety-hack.com/. He wrote songs and comic books about the Ruby language. Then, one day, August 19 2009, he disappeared and took all of his servers with him. Every project that he had created and hosted and maintained disappeared from his repositories. People were stunned—I had created a curriculum from one of his projects.
Matt: Perhaps he’s playing chess with Bobby Fisher.
Sarah: One of the best jokes I heard about his disappearance was that he had gone underground working on \"Perl 6\":http://dev.perl.org/perl6/faq.html and had renamed himself “when.”
The other thing that’s part of the ecosystem is \"Git\":http://git-scm.com/. Almost every Ruby programmer uses Git. Git is built for collaboration, and it is a modern source code control system. It makes it so that if your primary contributor disappears, anyone who contributes to the project has a complete repository. So when why disappeared, within 12 hours, there was a “whymirror” up on Github. Within days, there was a volunteer to take over almost every one of his projects. This is the incredible thing about the community: you don’t need to have your chief maintainer be someone who works for a corporation, who has a whole subsystem around them—I think this leads to this philosophy where individuals feel that they can publish stuff, and if it’s good others will contribute, and it will move forward, and you won’t be tied to this thing you built for the rest of your life.
Matt: So what are some of the other things, like Github, that you introduce people to? I know you teach classes—where do you point your students?
Sarah: I think that Introducing gems is really important, and showing them that it’s really simple to look for gems on rubygems.org, and viewing gems that the documentation for both Ruby and Rails comes from the source—its like Java docs, whenever you look at the documentation it always comes with a source code.
Whatever you need to do with Ruby and Rails, for 95 percent of what you need to do, somebody’s done it before—somebody’s written about it, or published a useful script for it, or a gem for it and it’s all searchable. One of the things I tell people is that if you’re writing some code that you think is probably in 85 percent of other web applications, do a quick Google search first. What this does is it liberates you to focus on what’s special about your application and about your code. What’s unique about this moment in history is that we’re building what we’re doing on top of the last 20, 40, 60 years of innovation and computers have gotten fast enough that reusable parts are really practical, and dynamic languages are really practical. Before, it was less practical to use dynamic language as introduction code--now we’re not gated by CPU Power; we’re gated by our ability to solve human problems and take them to market. Which means that we need to focus on communication, on sharing the kinds of things that will become commodity software next month or next year because, who cares? That’s not where the value is. The value is in problem solving.
Matt: All of these technologies seem to come out at the speed of light. For someone like an engineer who’s involved in a project day-to-day, who’s engaged with that one project, how do you manage it?
Sarah: It’s really hard, I will kid you not. But this problem does not come from Ruby. This problem comes from the world we live in. There’s a lot of stuff happening technically. Some of the perceived churn is kind of imaginary. It’s not like we invented the http status code. All of the stuff that we’re layering on top of hasn’t changed in, what, 15 years? Http is the same, DNS is the same, IP addresses are the same, but we’re mixing and matching them in innovative, exciting ways.
Matt: Tell me, what are some things you’re excited about that do seem really revolutionary and innovative?
Sarah: I certainly think that the network effects and the size of the data sets we’re dealing with create opportunities for innovation around visualization, around surfacing, and around relationships we used to have to search for. We can ask questions in more powerful ways, but also computers can be smart enough to tell us the obvious things that we really need to know. That’s where the true innovation is happening; how do we leverage these enormous data sets, fast CPUs, and the interconnectedness we have that is truly different.
Matt: You use the term “ecosystem” intentionally. Could you tell us what the difference is between an ecosystem and a community?
Sarah: When I think about the word “ecosystem” I think about sustainability, I think about growth, interdependence, and a number of organisms coexisting effectively together. Community means either the “we all love each other and we’re trying to bond,” thing or “we’re trying to create a community” a la 1990s: “let me hire a community manager, so I can have my customers fall in love with me,” etc. People were hiring community managers in 1996. This is not a new trend. Having a community manager is about getting your customers to save you money by solving each other’s problems. That is very different from a true community. Community is often achieved by creating boundaries with other communities. With an ecosystem, you often get a balance, where there are edges and terrain changes. But the word “ecosystem” speaks more to natural boundaries rather than to ones that are created to give a feeling of integration.
