Rinat Abdullin

As I’ve said in the previous post, Windows is gradually loosing the market to Linux systems. Such thing would obviously lead to the increased demand in software development for the Linux world.

NB: I’ll be talking right now about the desktop applications with the feature-rich UI and capabilities. That’s the Smart Clients. Web applications are partially immune to the problem of Windows-to-Linux transition (plus the efficient delivery and the maintenance of the feature rich UI is not something they are extremely good at).

Here are things that could possibly matter in the future for the desktop applications:

1. SUSE Linux Enterprise Desktop (SLED) is going to be one of the frontier points in the Windows-to-Linux migration, since it is supported by both Novell and Microsoft. This Linux system is also the most friendly to the Windows refugees (I’ve experienced that) and is supported by the major PC vendors (see the previous post).

2. The only rich and efficient development technology that is supported by Microsoft and Novel is .NET. It works natively under the Windows and with some limitations it could run under Linux or Mac systems via the Mono (see the list of the supported platforms). And Mono is the Novell’s project.

By the way, if you are deep into this new Silverlight thing – do you know that Microsoft has “announced a deal with Novell to have Mono provide Silverlight support for non-Microsoft platforms”? That statement delivers some message about Microsoft’s expectations on the future importance of Linux and Mono. And this company should have some qualified analytics.

Consequences:

• There will be demand for the developers/teams that could efficiently deliver solutions capable of running in two worlds (or in three, if you count Mac). That’s not a trivial task, since every operating systems has its own quirks (remember the consequences of the browser wars?).
• The market supply of the experienced development resources in this area is quite limited (and the entire knowledge area itself is quite specific and young) so the prices will be quite interesting (means “high”).
• The applications blocks and other recipes being delivered by the Microsoft patterns & practices group will favor solutions that add more flexibility to existing .NET solutions and simplify .NET-to-Mono transition. Novell would do the similar thing.
• Desktop applications will start using the “Mono compliant” logo and it will bear the same message as the “W3C valid” image.
• One of the big differences between .NET and Mono is in the UI. Currently developers could easily get astonishing UI by using components that hack deeply into the Windows API (P/Invokes and such). Unfortunately this experience is not easily portable to Mono. So there’s likely to be an effort to create some high level unified UI abstraction layer capable of rendering great UI on any OS (Windows Presentation Foundation?!). I just hope there will be no analogue for the ActiveX technology.

3. The most productive tool for the .NET development is Microsoft Visual Studio. Yet it is not ready for the Mono development. And #develop along with MonoDevelop still feel quite immature (and there is nothing like Resharper there). So the Novell and Microsoft could be delivering some solid Visual Studio Mono packages. They should let developers become more efficient in developing Mono-compatible applications (or porting the existing ones). I’m talking not just about the “Execute under the Mono VMWare image” button, but rather about code analyzers (some that bring MoMA capabilities to the new level), guidance packages and reference implementations.

Consequences:

• Virtualization technology is going to stay popular these years.
• Development machines will obviously require quite a number of hardware upgrades to support virtualization. This will corellate with the new FSBs getting higher, processors getting more cores,  DDR3 and hybrid memory becoming more popular.
• The actual development is going to get even more complicated (yes, the “quirks” factor again). So in addition to the simple unit tests, there will be more of testing of interactions:
• Functional testing.
• It will be a common thing for the integration servers have nightly runs of functional tests on multiple virtual machines.
• Diagnostics and configuration validation modules will be more common in complex solutions.
• There’ll be new component packages and development solutions that promise to make Mono development as simple as drawing a couple of boxes and assembling these together (these always do show up on any frontier).

4. There’s also the psychological factor – people will be more willing to invest in the software solutions that work in the both worlds or enable existing solutions to do that.

So the next years are going to be fun. Do you see here the opportunities of turning these consequences to your advantage?

If interested, stay tuned as I’ll be talking more about the LIM architecture of Landor and the changes we plan to make in order to simplify its transition to Mono.