The problem does not really exist in the world of Open Source software; and, even if popular operating systems, distributions and software packages are not currently available pre-compiled for ARM, it would not take long for the community and its sponsors to turn around and provided tested binary packages. For those that want to squeeze out as much efficiency and already roll their own compiled packages to servers, it isn’t too difficult to do the same for ARM servers.

For me, the biggest hurdle I see for Open Source software and ARM servers is the availability of developer and production hardware, along with the cost to acquire the needed hardware for testing. In terms of operating systems and distributions, the three main BSD projects (FreeBSD, OpenBSD and NetBSD) have one or more ARM ports available with the Ports and Packages repositories providing many of the required software packages used in scale-out hosting and compute environments.

On the Linux side of the world, Debian has had a small variety of ARM ports and Ubuntu has dabbled in the ARM space for a little while now. Fedora, CentOS and Gentoo are also viable foundations for building up Linux for ARM servers. There have been several Open Source and commercial Linux distributions that target ARM devices for real-time and embedded applications and can also be used to build up lean and mean distributions for the two server workloads that would excel on ARM. I do not know where Red Hat or SUSE stand in terms of ARM preparedness, but SUSE (by way of Novell and the partnership with Microsoft) may not want to stir the waters.

If the applications were written on top of various Open Source software foundations, such as Apache Tomcat, the various Python, PHP, Perl or Ruby frameworks, or other forms of interpreted languages and bytecode available from the Open Source community… porting and testing should not be difficult. Granted, the level of difficulty depends on the complexity and size of the application.

This leaves the two other major stalwarts in the operating systems market: Oracle and Microsoft. While Oracle Linux is Oracle’s own spin of Red Hat Enterprise Linux (or CentOS) and could benefit from either organization’s development for the ARM platform, the bigger concern would be the Solaris clan. ARM servers would compete against Oracle’s UltraSPARC T family of processors, not in terms of cores per server, but rather watts per core/thread.

On Microsoft’s side of the world, they have announced a form of Windows that can run on ARM netbooks, notebooks, tablets and desktops and would be part of the Windows 8 family. Unfortunately, there the lack of further details on whether that will trickle over to the next release of Windows Server and how serious Microsoft is on ARM development in general (outside of their current struggles with Windows Phone 7 on ARM). A half-arsed effort from Microsoft will hurt the prospects of ARM and could be seen as yet another form of “embrace, extend, extinguish”.

At this point, I don’t see the other major player in the ARM market taking the ARM server movement seriously… Apple. The ARM processor has been at the backbone of Apple’s transformation from being a computer and software company, to being a player in consumer electronics. Apple’s first venture in the world of ARM processors didn’t end up being a commercial success (at least compared to their later products with ARM processors), which was the Apple Newton. It wasn’t until the release of the Apple iPod did the combination of Apple and ARM make any kind of splash. This continued until Apple really broke ground with the iPhone, and later, the iPad.

Even with Apple’s success with the ARM architecture and processors, Apple’s recent exit from the server hardware market and integration of key server features into the base release of OS X Lion may not bode well for the hopes for a new Apple Mac server with ARM processors. I could be wrong on this, but all signs seem to point elsewhere.

So, at the end of the day, do ARM servers actually have software issues that need to be addressed? Yes and no. If your infrastructure is already based on Open Source software as a foundation, the source code and compilers are there and waiting to be used, particularly if you already roll your own code. If you are stuck on a closed-source and commercial platform with no access to foundation source code, well… that’s kind of what you get for depending on such platforms and foundations. Sorry for the bluntness, but that’s the core issue of non-Open Source software.