In my follow up to James McGovern’s original post on Ruby, I mentioned off handedly that the dialogue had been mostly respectful in the initial exchanges. Well, all I can say is that it was fun while it lasted.
As my colleague noted over the weekend, McGovern came out pulling no punches whatsoever in his clarifying remarks. The accompanying illustration to the piece, in fact, was a train wreck. That in turn provoked a predictable slew of responses over there, on Cote’s blog, and on a biting entry from the man behind Rails, David Heinemeier Hansson. The mostly respectful tone of the initial interchange? Yeah, that’s gone.
I was going to try and break down where the conversation went off the rails (no pun intended), but fortunately Anne’s done that for us. As she notes, this conversation has been conducted in fairly black and white terms; the kind of fundamentalist, binary discourse I find unhelpful. To me, that’s a shame. Perhaps Anne’s right, and we’ll all benefit from the dialectic, but I can’t help thinking it’d be more productive if everyone tried to find common ground. But wish in one hand, as they say…
As for where I personally stand, I’ve been fairly unambiguous on this already: while I concede the point to James that Java’s far more relevant than Ruby is to the enterprise, I don’t consider that a permanent state. Never is a long time. Maybe Ruby will become relevant to the enterprise, and maybe it won’t, but I agree with many of the other commenters that have pointed out that the arguments that James is using could and often were used against Java back in the day.
But there’s one point that James made that I did feel the need to respond to in more detail, if only because it seems so obviously wrong. I’m not sure if he’s playing Devil’s advocate here, but I can’t fathom where this came from, particularly in the context of some of the conversations we’ve had with James in the past.
Much of the guidance that the enterprises receive come from either big consulting firms such as Accenture, DiamondCluster, Wipro, Bearingpoint and others. If it isn’t on their radar then it probably won’t reach critical mass. Likewise, the other perspective comes from industry analysts who usually make irresponsible recommendations and oversummarizations of most problem spaces. In this particular scenario, industry analysts aren’t even wasting their own time talking much about Ruby. If you happen to see Gartner or Forrester establish a conference on Ruby then it will catch our attention, otherwise we will not pay attention.
As I read the above, the contention is simple: the Accentures, BearingPoints, DiamondClusters, Forresters, Gartners, Wipros dictate technical agendas, so if they’re not on board with Ruby the game’s over before it’s begun. I find this more than a little ironic coming from one of the single most vocal critics of the industry analyst business around, but it also just strikes me as fundamentally incorrect.
First, a correction. There is at least one industry analyst group talking about Ruby: RedMonk. And guess what? Some of the biggest vendors on the planet are listening to us. Why might they be doing so? Because they’re humoring a two person analyst firm, who admits to having little pull within the board room? Or because they see, just as they have with PHP, a potentially significant economic opporunity to monetize hardware or databases or other software that compliments a Ruby stack? My bet’s on the latter.
But forget RedMonk for a moment; my bigger problem with the above assertion is that it fails to provide an explanation for the gains that the LAMP stack has made in spite of having very little support from the aforementioned big consulting or analyst firms. One of the larger industry analyst firms, who shall remain nameless, boldly predicted in the late 90’s that Linux would be wiped out my Windows NT, after all. I know James isn’t a true believer in LAMP either, but I think it’s difficult to argue that LAMP – individually or as a stack – has not had a transformative impact on the enterprise.
Are the various components of the stack ‘enterprise’ ready? Let’s see:
- Linux? Here’s what one of the aforementioned big analyst firms said a month ago:
Linux servers generated $1.6 billion in quarterly revenue, the fourteenth consecutive quarter of double-digit growth, with year-over-year revenue growth of 20.8%. For the full year, Linux server revenues were $5.7 billion, placing it in third place for the first time from an operating system perspective as customers continued to expand the role of Linux servers into an increasingly wider array of commercial and technical workloads.
- Apache? The single most popular web server on the planet, 68% of the market to IIS’s distant second place, 20.61%, according to NetCraft’s latest
- MySQL? They’ve compelled ‘enterprise’ counterparts IBM and Oracle to release free versions of their products to better compete, and if the rumors have it, the latter even tried to buy them
- PHP/Python/Perl? I tackled these a bit in my original response, but it’s worth surfacing a bit more detail on ADP’s thoughts on PHP:
ADP’s legacy software runs on Unix platforms–60% Linux and the remainder Digital Equipment Tru64 Unix running on Alpha processors. It’s a green-screen application written in an antique programming language, Pick Basic, with SNA and X.25 networking. The company’s main competitor runs on the same technology.
ADP has been gradually replacing the applications, using mostly open-source components. The company chose to use the PHP scripting language, in part because of its support from IBM and Oracle. They used PostgreSQL, with a front end consisting mostly of HTML and JavaScript. “Where we needed a little more oomph, we used managed controls and .Net framework on the side,” Rankin said.
But does Rankin’s division of ADP – Dealer Services – qualify for the enterprise title?
ADP Dealer Services provides line-of-business computing systems to car and truck dealerships. The parent company provides technology including servers, and IP telephony; ADP Dealer Services focuses on applications, offering modules for accounting, reporting, finances, insurance, human resources, parts inventory and forecasting, and scheduling. Revenue for the business unit is about $1 billion, and for the parent, about $8 billion, Rankin said. The company’s customers range from mom-and-pop car dealerships with 15 to 30 employees up to multibillion-dollar corporations.
It depends on your definition, I suppose, but with revenues of a billion I’m inclined to bestow that title.
You might be asking what the LAMP stack has to do with Ruby, given that McGovern has clarified that his remarks are aimed not at dynamic languages in general but Ruby specifically. The answer is that each and every one of those technologies had to force their way onto the radar of the Forrester’s and Gartner’s of the world; some are further along that process than others, but all of the above have been discussed at conferences I’ve attended with analysts from those firms, so they’re definitely on their radar.
The point of all of this is that LAMP to me signals an important shift in the way the technology industry assimilates new technologies. When barriers to entry were high, it was far more true that some combination of analyst/CIO/vendor conspired to set the technical agenda and direction within large enterprises. Developers, lacking budget, were more or less at the mercy of the folks running the show – dependent on them for tools, databases and so on. And in many cases, as James points out, that’s still the case. But with the barriers to entry to many important infrastructure pieces – app server, database, web server, development tool – going to zero, the power has shifted subtlely but importantly. Many larger analyst firms haven’t yet quite digested the fact that the real power now – as evidenced by the success of Linux – is returning to the hands of the implementers themselves. Analysts might still be helping set the direction within enterprises these days, but it’s the direction that developers that have set for the analysts.
Don’t buy that? Then explain why Gartner’s Daryl Plummer felt compelled to write the following:
Web-technologies groups are now forcing the acknowledgment that Web services will indeed use mechanisms other than SOAP, WSDL, or even Universal Description, Discovery, and Integration (UDDI). Instead, standards such as Plain Old XML (POX) over HTTP and Representational State Transfer (REST) are asserting themselves as legitimate and very credible ways of delivering on the value proposition of Web services. As Web services assume more expansive definitions, we can represent them using a wide variety of formats and communications protocols.
While I certainly don’t take this to believe that it’s a victory for REST over the WS-* stack, I do think the very acknowledgement of its legitimacy is a win. A major one.
If, as McGovern contends, the enterprise technical agenda is set not by the developers, but by the industry analyst and consulting communities, is it really plausible that REST would become a legitimate option? After all of the time and effort those firms have invested in convincing enterprise buyers that they needed the complexity of SOAP, WSDL and one of dozens of WS-standards? We’ve been trying to get people to wake up to this for years, why? Because we listen to what developers tell us. And while it may have taken a while, it looks like that’s finally happening, though more because of communities like lesscode.org than anything we’ve done.
It may well be that McGovern’s right and that large enterprises have outsourced their own thinking and decision making to the likes of Forrester and Gartner, but even if that’s true, let’s not pretend those firms are autonomous or operate in a vacuum. Linux, Apache, MySQL and PHP didn’t get where they are today b/c firms like Forrester or Gartner were putting on conferences about them; they got there they are because developers liked using them, and subsequently vendors saw a way to monetize that. If Ruby can continue its upward trajectory within large scale development communities, it’ll force its way on to their radar just as it is on ours, for the same reasons. And from there, the language’s benefits – I’m with Google’s Yegge on this one, it’s far and away the simplest, easiest language I’ve learned – could well make it an enterprise player.
P.S. One of the commenter’s in McGovern’s piece was looking for Ruby w/in Eclipse; I suggest you try the Ruby Development Tools plugin for just the language, and Radrails for Rails support. Both offer the basics of Ruby within the familiar context of an Eclipse shell.
