Matt Asay wrote a well received post about dynamic scripting languages such as PHP, Perl and Python ‘crashing the enterprise party’. While the Indeed.com job trends chart that Matt used is somewhat misleading, the chart isn’t central to his point. I say somewhat misleading because the chart tracks percentage growth of jobs seeking “Java”, “PHP, “Perl”, “.NET” and “Python” skills. It’s not surprising to see languages with little enterprise penetration growing faster than languages, or platforms in the case of .NET, that are virtually de facto standards for non-legacy applications. The ‘absolute’ version of the Indeed.com job trend chart is more reflective of the market demand for Java, PHP, Perl, .NET and Python skills.

In any case, Matt’s concludes:

“No, Java and .Net aren’t going away anytime soon. But then, neither are the dynamic programming languages, which are increasingly blessed “enterprise ready.””

I completely agree. Forrester’s Jeffrey Hammond’s research supports the growing enterprise interest in dynamic scripting languages:

“It’s also no surprise to see that dynamic languages such as Ruby, Python, PHP, and JavaScript are proving most popular with developers in the 45-and-under cohort. Dynamic languages are useful when it comes to assembling components into composite Web applications, especially if runtime composition is important.

The implications? As the development staff at a shop turns over, the new generation will push to adopt these dynamic languages. IT managers must ensure that processes and application life-cycle management tools can handle the changes that these new languages bring to the development shop. “

Hammond’s research also found that developers are increasingly comfortable working on multiple programming languages. Hammond writes:

“Developers used to identify themselves by the languages that they used — “I’m a COBOL programmer,” “she’s a Java developer.” But that’s changing — less than 15% of the developers we surveyed spend all their time writing in a single language. “

I started to wonder if the increase in dynamic scripting language job postings is being driven by companies seeking enterprise developers with multiple programming language skills. For instance, if a job required Java skills and another job required Java, Python, MySQL, Ruby on Rails and PHP skills, Matt’s Indeed.com job trends query would find 100 percent of jobs seek Java skills while 50 percent of jobs seek PHP skills. Clearly, the first job has an emphasis on Java development, with Java coding likely making up the majority of the work week. The second job may also be a predominately Java job, but there may be the odd PHP coding task required. As such, claiming that the second job is a “PHP” job while the first job is a “Java” job is somewhat of a difficult conclusion. This can be remedied with Boolean search operators as I’ve done, as shown in the chart below.

The overwhelming majority of jobs requiring PHP skills do not require Java or .NET related skills. My hypothesis that the growth of PHP jobs was a byproduct of companies seeking a Java or .NET platform developer who also knew PHP appears to be unsupported by the Indeed.com data. Java developers tend to be compensated at higher levels than dynamic scripting language developers. Companies may not want to pay a Java developer to work some percentage of her day on PHP coding when a PHP developer could be hired for lower cost. Makes sense, but I would have expected more overlap between Java and PHP jobs or the .NET platform and PHP jobs. You learn something new every day!

Follow me on twitter at: SavioRodrigues

PS: I should state: “The postings on this site are my own and don’t necessarily represent IBM’s positions, strategies or opinions.”

I’m finally getting a chance to read up on the Microsoft interop news today. It really sucked to see the headlines all day, but not have a chance to read them until now.

While the words “open source” are mentioned in the announcement and on Bill Hiff’s post, this is really about open APIs, not open standards or open source. (Maybe ‘not’ is too harsh; maybe I should say ‘and significantly less about’).

Obviously Microsoft is opening up their APIs because it makes business sense. Google, Facebook, Amazon, etc. have already made the business case for open APIs to closed software. If you ask me, the interop announcement virtually eliminates (on paper) the argument that Microsoft will lock you and your data up. Hmm…have we seen this playbook before? Maybe from OSS vendors? “Use our product and you won’t get locked in. You have the source code so you can always go elsewhere if you’re not satisfied with us.” Understandably, Microsoft’s position isn’t as eloquent. However, it does counter a potential barrier to remaining a Microsoft customer. Let me be clear, I do not think Microsoft’s interop announcement actually protects against lock-in. It seems like Cote would agree:

“Overall, the thrust of the press release is that Microsoft is going to make the documentation and access to its software better (easier? Doubtful. See Joel’s piece), that is, more interoperable.”

But, it doesn’t matter what I (Joel or Cote) think. What matters is how Microsoft can market the anti-lock-in angle and how customers will respond.

I have never thought that OSS would be the end of Microsoft or the commercial software market. The fact that Microsoft is borrowing (in their own unique way) from the OSS playbook should scare OSS “freetards” straight.

Having spent the better part of my career working with products that are based on JEE, I sometimes have to remind myself that .NET is still quite prevalent. You’ll find that there are customers who are “JEE shops” or “.NET shops”. But a fairly large portion of customers have both JEE & .NET in their IT environments. I saw a Gartner estimate of JEE only/.NET only/ JEE & .NET/Other architectures representing 25%/25%/35%/15% of all customers. Take that “data” with a grain of salt as it’s old and based on my fuzzy memory. The larger point is that a significant portion of enterprises have both .NET & JEE.

We could argue about the pros/cons of each architecture, but customers seem to have voted with their wallets and use each as appropriate to address business needs. This statement could equally be applied to the OSS & Traditional software discussion.

I had the opportunity to speak with Jenna Dobkin from Mainsoft last week. (Mainsoft is an IBM business partner). Mainsoft provides .NET to JEE interoperability by allowing .NET apps to be cross compiled to run natively on a JEE runtime. I was intrigued by the technical feat behind Mainsoft’s offering. It allows customers with .NET skills and assets to continue benefiting from their previous investments while being able to deploy to JEE platforms. Why JEE? Well, it could be because customers want the performance, reliability, availability, etc. benefits of JEE. Maybe they want to shift towards open standards-based applications. Maybe their end customers are “JEE only” shops. Maybe dropping the “2” from J2EE did the trick!

Jenna put me in contact with two Mainsoft customers to understand why they didn’t *just* deploy to .NET or *just* write in JEE. Note the emphasis on my implied simplicity of the word “just”.

I spoke with Bart Sijnave, the CIO at UZ Gent, a university hospital in Belgium. I also spoke with Atul Mistry, VP of Technology at Urix, an ISV in the healthcare industry.

Both Bart & Atul indicated that their organizations had .NET skills and re-training their developers (teams of less than 20 in both cases) for JEE was not a viable business option. Bart suggested:

“If I had a larger team, I would add JEE-specific development skills. But I could not meet my customer’s time-sensitive demands if portions of my team were out getting re-trained”.

UZ Gent uses RHEL and other OSS products and looks for opportunities to expand OSS use as appropriate.

Atul said:

“Business is the key decision criteria for us. If you have to reinvent the wheel because of a religious technical belief then you are not doing the right thing for your business.”

Urix has customers whose IT environments are largely Unix based. Faced with not addressing these customers or adding new staff to port the application and continue development on Unix, Urix made the business decision to use Mainsoft. Urix also uses OSS technology such as log4net and other OSS technologies aimed at Microsoft developers.

Both organizations are believers and users of open source products. But, for these two companies, business results trump beliefs. I suspect this is the case for the majority of customers. This is why I believe that OSS will never truly “take over” the software world, nor will OSS fade away. Pragmatic customers wouldn’t allow either to occur.

Customers have to be pragmatic because their business depends on it.