This is part four in the series on selecting a technology platform.
Startups generally have more flexibility in picking a platform since many of the factors that would normally drive the decision (existing talent within the organization, existing products that need to be integrated with, existing code that has to be reused, etc.) are not as significant. Startups may also use their choice of platform as a differentiator (though this is dangerous and should only be pursued if you know what you’re doing).
A case in point is Ruby, or more specifically, Ruby On Rails (RoR). I’ve played around with Ruby a bit. It’s a great language and has a certain expressive elegance that is quite appealing. The runtime engine is also available for a variety of platforms. In this regard, Ruby’s a lot like Java. But, in one very important respect, its very different: Its new and unproven. Though there are many groups that are using Ruby to create very cool applications (particularly some of the “Web 2.0” companies), the language and the framework have not been around long enough yet to really know where things are headed. Though customers are unlikely to care what language the application is written in (as long as it meets a need and is reasonably usable), picking a niche language/framework/platform like this can have major consequences. Startups that choose this kind of path are assuming two things:
- That the platform will continue to grow in popularity and be supported over time (by supported, I mean that updates will be available, new people will be learning the language, books will be written, online forums will be available, etc.)
- That future partners, acquirers and others that do care about platform choice are not going to be important.
This last point is the one that worries me the most. I can’t tell you how many times I’ve come across a promising startup with “cool” technology that I think could have been a great addition to an existing product, but the overhead in trying to integrate it was simply too high. Examples I’ve encountered include Tcl, Python, Perl, PHP, etc. These are all great languages (well, maybe except Tcl) and yes, all of these have ways to be integrated using web services, but my response to this is that the integration is not deep enough and has consequences of its own. There is nothing like taking a bunch of C++ (or Java) code and reusing it at the “build” level (instead of trying to do some type of arms-length integration.
So, my advice is, unless you really know what you’re doing (and have some immensely compelling reason), try and stick with “mainstream” platforms. I can almost guarantee you that you’ll be glad you did (5-7 years later, when your chosen platform is still alive and well). This is one of those cases where there truly is safety in numbers. If you’ve got some product that simply must be written in a niche language/platform, then by all means, give it a shot. But, for most of us, mainstream platforms are generally a wiser choice.