I'm here with Zed Shaw and Matt Pelletier. You are a big presence at Ruby Conf 2006. I want to talk to you what you're up to. Why don't you tell us a little bit about your background?
Zed: I was basically a Java programmer for years and I have done other languages on the side. I was working at the Department of Correction in NY. I ran into Rail like anybody else did. I read the Curt Hibbs Article (http://www.onlamp.com/pub/a/onlamp/2005/01/20/rails.html) and started doing Rails that way. We started using it at the Department of Correction for a lot of apps. I started doing a lot of external consulting and shortly after that I started doing it on my own - about a year ago.
Matt: I'm a partner at East Media. We are a web software, mobile and business development agency based in New York. We found Rails in March 2005. I think it was a reference on Slashdot to the same Curt Hibbs article that got me started and we had known about Basecamp,but wondered what was used to build it. Once we connected the dots. I spent hours reading it and I was fascinated by it. In a few months I had turned this into a Rails shop in NY and started the NYC.rb group which is run twice a month and it's been great ever since.
The latest news with you guys together is that you got a book with Addison Wesley as part of the Professional Review Series and it's about Mongrel.
Zed: I was busy writing Mongrel, so Matt was working on the book. It's a small pdf book which is not quite vulgar but pretty entertaining! It was fun to write and I really want to do a bigger one.
For our audience who's not familiar with Mongrel, why another web server?
Zed: This is the same question a few other people asked. You already have mod_ruby, FastCGI and other fast things so the main thing with Mongrel was really simple. I just wanted something that was as easy as webrick but as fast as CGI and that's pretty much what I did. It's a stand alone web server, it works with other web server technologies, you can pretty much drop it in if you're on a Tomcat or PHP or anything else; you drop it right in and it works. Tomcat was my primary target for it because at the time I needed to replace a few Tomcat apps with a few Rails apps.
Who would you attribute the popularity of Mongrel to?
Zed: I think it was the right solution at the right time. It was just popular. I think it spawned more companies than anything else. Hosting companies, training seminars, everything is based on Mongrel now. I think it was popular because I documented it well; I released it in a working state - pretty much from the get-go - people can start using it. I was hanging out with the Rails core guys, so they were able to play with it. Some early adopters were able to get ahold of it, and then we were able to get with eastmedia and actually use it on real projects and make it solid.
Matt: Also Mongrel solved a lot of the pain that Ruby developers and system administrators have faced with Rails apps, which is FastCGI is the best solution but it's a crappy solution and scripts like spawn and reaper were created just to deal with the fact that FastCGI as part of the your deployment set up will cause dead processes.
This was all kind of a hack right?
Matt: The code for the archaic FastCGI hadn't been touched in a couple of years yet this happened to be the best way to run a Rails app. So translating a request from a server like Apache to the FastCGI module and turning the request into a CGI request and then loading it into Ruby environment; there are too many steps. Mongrel is a real web server: it speaks HTTP and it's Ruby. By the time you send a HTTP request to something like Apache directly to Mongrel it already has the Ruby environment loaded.
One of the things that was surprising to me was not only that Mongrel is a good solution to Ruby, it's actually a solid web server on its own right, being solid in terms of security
I spent a lot of time trying to make secure and that was actually quite a little bit of the research in Mongrel. Most of the web servers out there use hand written parsers, a lot of hand coding and hackery to process requests. The majority of that is just from the sample code and from within documents like the RFCs. In Mongrel we took a different approach, we wrote a parser and with that we were blocking security attacks against several different web sites. Just by the fact that it was a real grammar and it rejected HTTP that didn't match it. That's the research aspect of it. Switching to parser didn't reduce performance and improved its security right from there. But also it did other things like code testing, auditing, fuzzing and various other techniques that tried to make it solid. Primarily because the first thing you get from folks that have java and enterprise background is the security; they worry about the security of their stuff. I want to make sure that this is my policy and this is how I did it.
You just gave a talk at Ruby Conf about RFuzz and Fuzzing in general. Can you summarize what it is?
Zed: Fuzzing is basically handing random junk to a program. The amazing thing when you do this is that the program tends to break. When the programmer is writing software, they are expecting certain inputs; when he receives unexpected input, it breaks. Fuzzing works amazingly well, so with these techniques I had I've been able to make Mongrel pretty rock solid. There are some things it can't get around because the way Ruby does stuff, but otherwise it protects against everything.
Lately you have spent a lot of time working on a project that has a lot of security aspects to it. Can you tell us a little bit about that?
Matt: We were contacted early in 2006 by some folks from VeriSign Labs; they had a Ruby prototype of a server implementation of this protocol called OpenID. OpenID is built as an identity 2.0 technology for being able to have distributed sign-on and a universal way for giving access to your profile information and store it where you feel comfortable with.
Zed: The buzzword is SSO (Single Sign-on)
This would be like single Sign-on, for the whole internet – not just the enterprise?
Right. Things like Passport have had many attempts at this kind of thing - It came out in 1996 and it failed soon after. The only place it is used today is on existing Microsoft sites: at least that's where it is popular. One of the reasons it failed is because it is a centralized big brother service and people felt generally that Microsoft should not do business with transactions that it shouldn't be a part of.
VeriSign decides that it wants to get into this. They built their prototype in Ruby and they turned to you.
Matt: They wanted to take that implementation and make a professional, clean production application with it, one that could stand all the kinds of traffic that a company like VeriSign could send to it.
What kind of challenges did you run into trying to turn a prototype into a slick, professional clean platform?
Matt: There were aspects double related to the protocol itself because it is still considered in development and I fact is in 2.0 is still being worked on right now. In terms of Rails and Ruby there were some interesting constraints we had. One was testing. One of the reasons we decided to use Mongrel and have Zed build out some functionality on Mongrel was because with the open IDE exchange you have a client site like a blog or an e-commerce site and you have your server which serves your user profiles. Then you have the user engine in the middle which is your browser. Now you have two parties with a browser session in the middle and you need to run unit tests, functional tests and integration tests for just one single Rails app, but we have two. Then we need to be able to run tests between all three because the complete sequence is really across two different apps through a browser session.
You innovated a lot to be able to do this?
Matt: We used Selenium and we had hack it a bunch to get it to perform a specific kind of test we wanted, but that was a key element. Then Mongrel, because Mongrel is all Ruby, we knew that any aspect of an HTTP request coming or going with Mongrel would be fielding that request. That gave us really good access to the requests.
If a company like VeriSign is getting into this I would guess that is because it's going to be used for not just authenticating to blogs, but for serious e-commerce stuff. Money can be at stake which means security is a big issue...
Matt: One of the reasons VeriSign wanted to help push it with Rails is because it recognized that a lot of Rails developers happen to be aware of where things are moving on the web. They seam to be pretty sensitive to innovating and try to build better products and do things in ways that they are not blocked by something they were taught 5 years ago.
Given the state of Ruby as being fairly new and Rails being fairly new, just a couple of years since everyone started working on it, why does that make sense from a security stand point? Some would say that Ruby is a toy language (obviously we don't agree with that)..
Zed: There are 2 factors: they have to have a fast roll out and already got approval. There's a "under the wire just to see how it works". And the second aspect of it is that they already have existing Java but we were able to do the Rails applications and still fit in with their infrastructure, they didn't have to change their load balancers and firewalls. They have a lot of their security on that side, they don't really put it so much in the application, and then they were running the same penetration tests and stuff that we were doing. It didn't mater what language they used, they still do the same techniques, the same testing, whether it's Java, PHP or so on.
Matt: Which is another reason why Mongrel was a good fit for the project, because it was designed to snap into designed configurations and works in the standard LAMP stack: VeriSign used Apache for the front facing webserver alongside a generic Linux install. So you have Apache acting as a reverse proxy to a Mongrel cluster, talking to a database based application. They didn't have to reinvent the wheel, all they needed to do was pull out the Java pieces and put in the Ruby pieces.
Zed: So if you imagine if they are doing FastCGI, all their testing tools, all their methodologies would have to be redone. With Mongrel they didn't have to do that, they could run their same test tools, etc. They can get their tiger and QA teams in, who would see it was the exact same application: nothing had to change.
That's a good point for people who are trying to introduce it into their similar circumstances
Matt: Right. Those are the big designs of Mongrel.
Zed: The thing to take away from this is that it doesn't matter what language you use, it can still be crap and have bad security, you got to rely more on your testing methodologies and security policies. These policies have to be set by management not by the guy writing the code and the system administrators. You got to run those no matter what language it is, don't trust any language. But because we ran through, Mongrel is powering a lot of companies right now; it's got some credit now.
Matt: We have build a lot of automated testes especially with Selinium, we have written all our scripts to actually go through every one of the existing open ID sites, and perform a login through that site using the server application that we were building, and we could actually make a video, literally a screen cast. It showed every one of those tests running, so we could then show it to the managers who needed to see what was happening and that we had the right practices in place.
That must have made a big impression on them
Matt: It did, because they can see what is happening and they can understand that there are tests written. The QA teams going through their acceptance testing is essential, but having automated tests is a big deal. So the fact that we had come with a lot of these practices in place, added to the confidence that normally what would be considered a risky framework or a risky language doesn't have.
Maybe it's a little redundant and tell me if so, but what kind of impression did it make over all? You said this fitted into their existing environment pretty seamlessly. Did they see it as simply just another tool in the tool belt or were they actually impressed and said "oh, we want to move to using more Ruby"?
Matt: I think there is definitely an interest now in wanting to use Ruby more, it's demonstrated that it's capable and I think companies like Verisign or other commercial companies are going to start understanding - especially when they have good examples (like this application that we built) of professional enterprise grade production sites.
Zed: It brings to question a lot of the accepted wisdom of Java, and that it takes you 2 years to do something like this. If one small company of about 5 developers can crank it up within a month or two you start asking yourself questions.
Writing a web server as well..
Zed: Yes, full web server, full tests, videos of the test running. It's a cost; it comes down to pure cost. If 2 things function the same, and one is simpler and takes less time and fewer developers you got to go with what is the cheapest.
Matt: We've worked with some companies and have seen this kind of thing as well: you spend more time dealing with paperwork and meetings, and discussing specs then actually doing development time. The planning is now less than a heavy labor and more of a smaller execution task.
Let's not fool ourselves: that is the status quo out there...
Matt: The meetings and paperwork, they are not going to go away, but the part that changed and that helps make people understand more quickly is when they see that a real project, start to finish, took 5 weeks for 3 developers including the designer, including the guy writing the web server, and including all the tests and a bunch of automated QA. That's not possible with some of the heavier frameworks.
Let's explore that a little bit, because there's a certain magic going on here, and if I was looking at this from an outsiders prospective I would say "well these guys are actually just world-class, they are very talented, I can't afford those guys".
Zed: Two things: from the developer point of view you will either feel threatened or they'll say "there is no way we could be like that, those guys are really good". From the management point of view you say "why don't you be like those guys?" Whenever a manager reads an article about the NASA software team they ask "why can't you be like those guys?"
The thing is that you don't take one situation or what someone else did as proof it will actually work for you. You need to sit down and actually try it. Trust more pilot projects, put a willing developer who has interest in Ruby on Rails on the project. At the Department of Correction, Rails started because we had a bunch of VB developers that have been there for more than 20 years and Rails was just easier for them to learn. And then I just sat with them and they just said "we want a project done in Java, I can do that in Rails in like a day" and I just do it. And that's the thing: if you are a developer, and you want to do Rails, don't try to do the company's website; do that little HR project for example, that has always been on the back burner. Something small that nobody cares about. And for management, if you want to get serious about Rails, start a pilot, really make sure it works, they might not work for your culture, they might not work for your deployment, you might have a lot of animosity for it, try it out first.
Matt: There's a lot more intelligence built into to some of the practices and philosophies that go into something like Rails, which drew a lot of these things that Ruby had built in. And we found that the project development process, the project management, even product development, is leveraging that intelligence in different ways, it's not just building a staircase knowing what the blueprints are and going through the motions.
We built some bigger Content Management Systems recently and we found that we were spending more time deciding what the application logic would be than actually writing it. That's because Ruby and Rails (being an excellent DSL for web applications for Ruby) trivialized a lot of things. We had files that were 4 lines of code, that accounted for functionality that we swore, even being Ruby developers, would take a couple of hundred lines of code.
Arguably Ruby and Rails is moving into the mainstream fairly quickly. Does this change the magic? Does the situation change?
Matt: One of the things that needs to be watched out for, is as a developer looking at Ruby or looking at Rails and then looking at examples and copying them, not really trying to understand why those tools are as good as they are, meaning they are going to replicate what they see, and follow practices that probably aren't good, or are specific to the example they had. You're going to see a dilution of talent, because there are developers that just don't really care, aren't interested.
Zed: I had that experience. I did a small consulting project for a company and there were 2 Java developers and a software architect, they had me for a couple of hours and wanted me to teach them Rails. Nobody wanted to learn Rails; nobody was interested. So what we ran into was that the Java developers didn't care, the software architect was trying to do frameworks on Rails, but Rails is already a framework, so it was a total disaster. That's the thing, you'll see developers who are going to try to say "oh I can do that in Java", without understanding how it actually works.
What do you do as a consultant in that situation? Because a lot of the guys watching this video are going to be in that situation, because they are fans in their enterprise…
Zed: I'm actually thinking that you don't make your developers do it, you wait until they come to you, and it doesn't have to be Rails, it can be any of the other slick smaller frameworks, such as django, etc. But if you are trying to get better productivity and you are seeing that whatever you are currently using is really lame, wait for the developers to come to you, ask them to find something else.
That's the first thing and the second thing for me is that I won't be in that situation again; I would have to see that everyone is really on board, they are already doing Rails. If it's an internal system I would just go with the general wisdom: you have to have someone high up championing it, basically threatening the fire people if they don't do it. That's about the way it works. But I've had a lot of success also coming into the backdoor writing small stuff that people used all the time, and was done quick, money wins.
Matt: I would say that a lot of the strategy comes with knowing how to understand what the goals are of the person that you are talking to. If you are speaking to a manager who is slightly technical or technical enough that they understand that Rails and Ruby has something of value, but they are not quite sure why, or they are concerned there are many other pieces of their infrastructure that need to be connected to or dealt with might be problematic because it's just hair raising, seeing Ruby as subversive.
You know a bunch of Ruby people, what do you say to the manager who's worried that he is not going to be able to find Rails developers, to staff his projects and do maintenance and stuff that people like us write for them?
Matt: I usually say we'll help them find people. What happens a lot is we get work on projects where we build an application and once it's built we hand it back to the company so they can maintain it. Companies will have some PHP developers who knew a little bit about Rails, and told the manager about it and the manager said "we can go find somebody to do this on Rails". What happens is we go train them. In other cases we just continue doing maintenance.
Is this a myth that there are not actually people out there?
Matt: I think one problem is that the developers who are interested, and ready and willing are scared that they won't be able to find jobs. There's no shortage of Ruby and Rails jobs. We get a lot of requests, for totally reasonable projects, a lot of internal projects, a lot of projects that are front facing consumer sites and a lot of start ups too. We are not getting requests specifically for Rails, sometimes they just ask because it's a celebrity technology right now, and sometimes they actually did the research, they understand why and they understand what is important about it.
Zed: The way the VeriSign project was done is a very good example of how you should do it. There's one guy who is interested in OpenID, tried it with Rails. He was able to bang out a prototype and get some kind of support for it. Then he went to some guys that will do it and put it together. That's a lot easier than coming in and using Rails because it's popular.
Since you mentioned that, have there been any cases yet where you said "I understand you are asking for Rails but Rails isn't the right solution for you"?
Zed: Yes, many times.
Can you give us an example?
Matt: A lot of companies have a need for ebb and flow for developers. Sometimes they have an on-going site that they have launched and they have a big roll out and they want to have sort of a faucet that they can turn on and off. While the community is not as small as it used to be, it's still not nearly as large as the PHP community or the Java community, you can't hold your arm out and catch a few in the wind. So for some projects even if they have some infrastructure in PHP and they want to rewrite it in Rails and they want to build a mesh of the two, we'll usually say no.
Rails was a shock to a lot of developers, and now it is to a lot of managers and people who are reading about it, and see that there is something legit about it because it's not just the language, it's the philosophy, and that's why you see a lot of Rails knock-offs in almost every language there is, because they are leveraging the same philosophies that Rails leverages, they just have a lower ceiling, because the languages themselves are not as flexible as Ruby, so we'll actually tell some people that if they have an existing PHP application go check out Cake or go check some of the other PHP libraries, or Drupal.
Zed: In my experience, it was the same contract where they really wanted to learn Rails, it was management that wanted to do Rails, and the developers just didn't want to do Rails, they were not interested and I said "look, you really shouldn't be doing this; you should just stick with Java". And one thing that a lot of people don't get is that you can do this stuff that makes Rails successful in any language: the key is keeping it simple, don't over architect it, start small, slowly build on, and what you get with Java, .net, a lot of these frameworks that have been around for a long time is they just over architect things. And so the manager basically explained to me that he wants Rails, because the philosophy that comes with it will counteract the software architect that has already gone to architecture astronautics.
Matt: You don't need an architect. Rails provides lots of that structure. It totally meets the 80/20 rule in a lot of cases and especially in more complex enterprise situations and integration requirements, it's not that simple but that's 80% of the time, you don't run into architecture worries.
Zed: From my experience with all the different internal software that I have written, most of them being internal operational software, I always say that the first thing I would do if I was doing Rails is fire all the software architects and hire graphical artists and interface people. That would be the first thing I would do. That's just my point of view, but from my experience, a lot of times this is already decided for web applications. I would actually not fire some of the folks, I would move them to be more integrators, they would be working on the application integration, enterprise integration, they would be working on the cross departmental stuff.
There is still nitty-gritty code stuff to do in Rails apps, right?
Zed: Yes, but not architecture, it's decided - Model-View-Controller - you do it this way. With integration across applications, you need architecture there. You need coordinators, you need planners, you need people doing that, because that's really difficult. It involves heterogeneous systems, and multiple languages and architecture. That's the cash cow. That's ThoughtWorks and the stuff they do.
Let's start drawing to a conclusion by looking a little bit into the future, applying what we seen. History repeats itself, so when Java started out for instance, one of the reasons I got into Rails myself, is because I heard the same sort of objections to the adoption of Ruby on Rails that I did with the adoption of Java, when C++ was the norm.
Zed: Exactly the same thing!
This gave me the goose bumps - it was a chance to jump in because the cycle seems to be the same thing. Of course that means that Ruby on Rails could go the same way that Java has gone over the years, to this quagmire of complexity.
Zed: That's true. I think the long-term prediction would be that languages are going away from the monolithic generic language and go more towards being very good at specific things. Like the PHP and Ruby on Rails is a good example.
Ruby on Rails as itself is a language…
Zed: I think we are going to see more languages moving towards that. They won't build systems, but they are going to do what Forth, Scheme and Lisp were doing decades ago. We build languages, little DSL languages that people use to get their work done. What we are going to see is that dynamic languages, Microsoft and all these companies are backing it.
For the short term though I think there is going to be a crisis really soon within Ruby, with the huge number of virtual machine competitors that are coming out. The number one warning that I am going to put out there is that when you've got around 7 virtual machines, when everyone is trying to be the king of virtual machines, I think that's going to be risky without a really good specification on how a language work.
How will something like Legion (the Ruby VM test suite tool) alleviate the fact that you don't have specifications?
Zed: It helps! Actually the best thing would be to download all the gems and try to run them. They all have test suits and if you are able to run all the gems that's very good. Choices are good things, but even within the Ruby community Matz is working on 3 different interpreters, at some point you run out of people to work on stuff.
Is it really necessary to have a new virtual machine before Ruby really hits it big time?
Matt: It depends. If you are doing Rails applications that are considered moderate to large sites, and you are not doing a lot of things in the backend that are not web related, probably not, because you can solve those problems with hardware. But a lot of the issues that Zed and I have seen in Ruby are dealing with lower level stuff that any professional code auditor, or any team that is dealing with professional investigation of putting a language to its paces, will see.
It is going to happen in any major company that it's going to want to take on Ruby because they obviously see the benefit, but it has to come with the risk. They are going to have to figure out whether or not they think it's valuable, and some of those things I've not yet encountered, because I don't have a need yet for accessing threads (for example), even Zed writing Mongrel hit a bunch of issues.
Zed: I would say that the big 3 hit list for me is: garbage collection, threads and IO. Those things are important because I'm closest to them. They just constantly have problems and you don't see a lot of fixes for them, you don't see people working on it making that happen.
Matt: In terms of what I think will happen in the near term, there's no such thing as long term with any assurances with Ruby, or Rails, this stuff just moves so fast, we'll start on projects and I have to go spend a couple of days after the end of the project catching up on what's happened with Rails because they are adding so much good stuff.
Zed: I'm the worst Rails programmer because I've been doing a lot Mongrel, and haven't touched Rails since 1.0
I have tried to write a Rails book last year…
Matt: What I think will happen is a lot of logic companies are going to start paying much closer attention, they are going to be looking at Ruby for the right reasons, not because of some magic thing that will solve the budget problems, and some of them will encounter the same things that the small teams that are drilling deep into Ruby's internals have run into.
But I think commercial support of Ruby will help a lot, a good body of people that have the right kind of approach, and it is always tough to determine what that is, but the right kind of approach to the evolution of a language beyond the borders of the small community that has started it and has grown from.
A lot of the problems with these lower level libraries are not really hard to solve problems, they are just are not receiving the right amount of attention, because the people who develop them and have been using Ruby for a decade, is a different set of people than the ones that have now taken a look at it in the last 2 years.
Zed: And there are also some changes in the way software develops, from since the time Ruby first was made and right now. You can see there's a lot of weird cruft and strange things that are done, even Ruby conventions that have been adopted, like not using camel case. You go and look in the CGI library there's camel case function names. It's little things like that. I would really love a purging but I don't think that is going to happen any time soon.
Here's a slightly different twist on the outlook question: who's going to get rich with Ruby in the next few years?
Zed: Books. Books and training.
Matt: And unfortunately probably some folks who don't have Ruby's best interest in mind, or the development side of Ruby in mind, that are going to make commercial packages that bleed some of the value in order to reach a part of the market.
Zed: I will make one remark really quick exactly on that: I guarantee there will be a Sun approved enterprise Rails. They will put "enterprise" on something, once JRuby is solid and running on Rails I can guarantee they will come out with a product that integrates Rails applications into their stuff.
Why is it a bad thing if I can take my Rails application and deploy it on EA?
Zed: It's not a bad thing and I hope JRuby runs rock solid, and I can start using it for a lot of projects. The bad thing is that Sun has a history in taking open source projects and wiping them out and using its own. So take log4j, anything in the JCP pretty much. And even people within the JCP said that they really don't like the way Sun uses it to further their own gains. History repeats itself and companies have to make money, it's not evil but you got to look for it.
You mentioned commercial support, as one thing that is needed. Who's going to be the JBoss for the Ruby in the Rails world? It's not going to be the core team, according to you.
Zed: They are not interested in that.
Matt: They are deliberately and quite vocally not interested in that. Even when it comes to extensively supporting some of the incoming requests they get. On one level it is completely reasonable as a philosophy, but at some levels there is also arguably a responsibility now that the framework is being used so much. People who will take on that responsibility will be the ones who are savvy enough to know how to make money out of it.
That's where they are going to create packages, service contracts and all kind of service and product oriented solutions that are thinking more about the bottom line then they are about keeping the integrity of the language in the framework, which is expected, that's what happened with Java. Microsoft has a lot to gain by being able to take Ruby and compile it to CLR.
Zed: With Java it was the same, there was about 2 years before you started seeing all kind of alternative commercial products, even Sun wasn't really selling it they had some set top boxes and things they were trying to do.
Once Java enterprise came around…
Zed: And there were also and it started seeing, that Sun cared more about the company selling Java stuff than the developers using it. I think that's why you had so many defections later. And that's what I would warn people against, if you start using Ruby and Rails go more for the company selling it…
Once you have different versions of Rails running and someone proposes a "R2EE" spec..
Zed: I'm going to do that! It'll be the Mongrel enterprise edition…
Will there be a Mongrel enterprise edition?
Zed: Yes, as soon as I can make it solid enough. I want to do a box with it.
A box that costs tens of thousands of dollars…
Zed: But it's totally worth it
Matt: Completely different software than the regular version.
Zed: Actually I've been toying with support contracts and have worked with different companies that were doing it, to try to see how it works. My take on it is similar with the Java approach. I don't think the market is ready to buy support contracts yet because primarily the people who buy support contract are internal corporate and government agencies. The people that set up, like Matt and other folks, they don't buy support, they are do-it-yourselfers. The Engine Yard guys and Rails-machine people don't need support contracts. Support for them is just keeping their servers running.
Sometimes they need it to get it rolled out into production…
Zed: Sometimes, people using those services might, to get it right. But really, you are going to see that as soon as someone has a way of marketing and getting it to internal customers that have to have contracts, just because they are required. Government agencies are classics - they have to have them. Then they can use it, they have to spend $30,000 on a one year contract. That's the deal.
I have actually been advocating this, and it's the reason why I wrote Mongrel: if you want to get Rails inside companies and internal organizations it has to fit with what they have now. They are not going to swap out their load balancers to do FastCGI. That's why I think Sun has a cash cow potentially. If they are able to take a Rails application and pump it into a web sphere system or similar, there is money there. Because that's the less you have to swap up to run this stuff.
For those of us who get involved in this sort of thing, the message is, "try not to be evil"?
Zed: I have seen this over and over, I have been doing open source since I was 18 so for many years, and I have worked at IBM when the dotcom bust happened, I saw that hundreds of companies go down. And it happens the same way, as soon as Open Source starts making money; the cash vultures come out of nowhere and start picking at the pieces.
This is why DHH is very strong about developing for the developers, it's for me; I really like the way this works. And that fends them off. The only people that it doesn't fend off are the book writers and the publishers.
There is some stuff that they do - like the pragmatic programmer guys who hang out in rails-core, but otherwise I like that because it's more pure. Once there's cash to be made, things will be different. You'll start seeing much more people coming out and bastardizing it, doing their own things, marketing FUD and fluff that will be different.
Matt: One thing to focus on also is even if you are a manager, or a system administrator, someone that has no need or concern, and legitimately you don't care what the details of the development are, it doesn't matter what the name of the programming language is, just you know saving money and time is better.
Those things that add value that make Rails and make Ruby really solid are the dedication, effort and passion of the people and the work has gone into it so far. So as soon as the commercial efforts pick it off the ground and bring it into the highest sky, there's going to be an inevitable dilution anyway, but don't be evil, keep in mind you are actually making your own job harder or making the product worse, if you are not keeping in mind, try to understand the philosophy.
Zed: I will give you a really good contrast: there were changes to how Java servlets worked that only satisfied the vendors of containers, like being able to access sessions, very classic example. When that came out it destroyed tons of code I had, we had to throw working code out and screwed me over big time.
By contrast, you can trust Microsoft; it is very good at making sure developers have everything they need. They got great tools, MSDN is nearly free, cheap and by comparison, they know that if they put other product that screws over developers they will move of to any of the open source that are out there. And that's something that SUN and IBM and so on haven't figured out. Every time they took Java and made it so they could sell more stuff, like when they took EJB and made it so they could sell more stuff, they were actually making it more difficult for developers and developers if they see something easy coming along, they are on it.
Matt: And the term that goes around a lot is "I'm a lazy developer I don't really feel like doing extra work".
This is another way of expressing productivity?
Matt: Exactly. If I find things that help me build better products, working on better projects – then I want it.
Zed: And that's why it goes back to my comment that I would get rid of software architects and move in as many graphic artists and designers as I could because that's actually what's hard now. Before it was all architectures and architectural decisions that were hard, now the difficult part is how usable it is, how do they get it? And then the actual putting together the website is fairly simplistic.
Matt: You don't have to be a software developer to understand the difference between using something like Visual Studio which is a very nice but heavy IDE, (we've done a lot of C# development and .NET over the years) compared to the Ruby way. To go from learning Ruby code in a text editor with syntax hi-lighting to using a heavy tool with dragging and dropping objects, generating code that you don't see, then understanding the difference between those two things and how Ruby development is a much more clearly the path with least resistance from the developer. If you are a manager, pay attention to that.
4 comments
Reply