I'm at the QCon conference in London, one that I particularly value for its vendor-neutrality and strong content. Yesterday we heard from Robert Martin, founder of Object Mentor, on the subject of software craftmanship, or how to avoid bad code. One of Martin's points is that having code that works is not enough. He makes an analogy with a machine. It's not enough that your car works; when you open the bonnet you want to see good engineering, not a tangle of pipes, wires and belts that somehow hangs together.
Software is vulnerable to poor craftsmanship because code is often well hidden from customers and end-users. Still, the programmer knows whether they are putting together something that just about works, or crafting something excellent that will be understandable and maintainable long into the future.
Martin's talk turned out to be a practical one. There was nothing really new; but plenty to think about. Here are a few of his tips:
You may not agree with all of these; but I like the underlying objective, which is to code to a high standard rather than just fixing bugs until it runs.
Agree? You can sign the Manifesto for Software Craftsmanship.
I've written positively about Microsoft's forthcoming Visual Studio 2010, both here and more recently in a review on The Register. I was interested to see a kind-of follow up from Jeff Vroom, making the case for doing without an IDE at all, at least some of the time:
Emacs, Vim, and other editors have basic syntax highlighting and code navigation for an even broader set of formats despite the fact that they lag behind IDEs in features. Though IDEs offer impressive plug-in capabilities, traditional script and config files seem easier to learn and use and ultimately more flexible.
Command line workflows offer a more flexible, less integrated and less guided approach to development. You learn how to use them one tool at a time. Development and adoption of new tools is usually easier as you are not tightly coupling tools into one complex user interface. Admins, analysts, and designers use command line tools, making it easier for them to work with developers when the IDE is not front and center.
I don't see a lot of designers using command-line tools; but even so I agree that there is a case for a programmer's editor with command-line compilation, rather than a huge IDE. The two things I like most about the bare metal approach are speed and transparency. Speed, because a little editor like Notepad++ starts in a blink, handles large files with ease, and does not get in your way. It is odd that performance still matters so much in an era of multi-processor machines with each core running at more then 2 GHz; but it does. Sometimes I am caught out when a monster like Adobe Dreamweaver grabs a file association for something like HTML or PHP. I double-click a document, and wait impatiently while it loads all sorts of stuff that I do not need, when I only want to make a small text edit to the code.
Transparency is an even bigger issue. If you work with simple editors and build from the command line, you are forced to be aware of what files are in your project, what tools you are using for the build, and what arguments you are passing to them. If something goes wrong, you know where to look. By contrast, IDEs hide things from you, supposedly for ease of use. In the worst case, something like a Visual Studio solution can get corrupted and leave you not knowing how to fix it, other than to create a new one and add back the files as best you can.
A similar problem comes with wizards that generate code. It is lovely to have the IDE generate all that boring data-binding code for your forms, until there is some weird bug, the results are not as expected, and you end up tracing the SQL and puzzling over why it is wrong.
Valid points; but I am still going to come down mostly on the side of the IDE. It is simple: there are so many genuinely useful tools in something like Visual Studio that productivity is better. Things I don't want to do without include IntelliSense and code completion, debugging tools with things like mouse-hover variable values and watch windows, visual design tools that generate a ton of code I don't have to write, various refactoring utilities, and build tools that save having to think about make or Ant. Visual Studio takes ages to load, but once it is up and running you can always press Shift-Alt-Enter and pretend it is a text editor.
I am still wary of wizards though; and I value knowing how to do without the IDE, even if most of the time I end up using it. As one of the comments to Vroom's piece notes, if it gets to the point where your programming skills are really IDE skills, you should worry about being so deeply tied to a single platform and way of working.
Microsoft has made a release candidate for Visual Studio 2010 available for download, and the rumour is that the final build should be ready in time for the official launch on April 12th. Should you care?
I'd argue that Microsoft's platform is in decline, despite good financial results recently on the back of the success of Windows 7. Windows-only development is increasingly unattractive in a world where Macs, iPhones and Linux devices such as Android and some netbooks jostle for attention alongside the once all-conquering Windows PC. Microsoft does internet too, of course, and even cross-platform for the desktop if you count what is coming in Silverlight 4.0; but even after the launch of Windows Azure this month, the company is not the first to come to mind when you think cloud.
That said, Visual Studio 2010 is a mighty impressive release. It is not just a new IDE, but also includes .NET Framework 4.0, the first complete update since version 2.0 in 2005. Versions 3.0 and 3.5 used the same underlying runtime as 2.0. The Chief Architect is Rico Mariani, Microsoft's .NET performance expert, which has no doubt helped in the tricky transition to Windows Presentation Foundation for the Visual Studio editor and shell; and much of the product is under the oversight of VP Scott Guthrie, one person who still knows how to communicate with developers, and whose presentation on Silverlight 4.0 rescued last year's Professional Developer's Conference from tedium.
Leaving aside the people involved, there is a ton of interesting stuff to explore, including the new F# language, IntelliTrace debugging that lets you step backwards through code, standard UML diagramming, source code management and issue tracking through Team Foundation no matter how small your team, greatly improved libraries and tools for concurrent programming, and if you have the Ultimate edition and the patience to set it up, an extraordinary thing called Lab Management which integrates virtual machines into the automated build and test cycle so that you can verify clean installs into complex multi-machine environments on every build, and use snapshots to analyse bugs at the moment they occur. This is also the first release to be designed with ASP.NET MVC in mind, and to have a full visual designer for Silverlight. Microsoft has also done some good work with Windows Workflow Foundation, in conjunction with a new runtime for the IIS web server called Windows AppFabric, making it easier to build and deploy applications that depend on long-running state management.
There are some disappointments. One is that Visual Studio is out of synch with Silverlight 4.0, so despite developer attention having largely shifted to the 4.0 release, Visual Studio 2010 will ship with Silverlight 3.0 support. There will be an add-on in due course that will put that right. Another is that Windows Azure development is not as smoothly integrated as I had hoped. SharePoint development, while much improved, remains an arduous process that tends to take over your development machine; and there is not much new in mobile development as yet. I am sure there will be plenty of other problems and frustrations; so much here is new that it is nearly inevitable.
These issue have not stopped me from enjoying my work so far with the beta and now the RC. If you have any interest in Microsoft's platform, I suggest you take a look.
So you need a new Windows application. You fire up Visual Studio, but which project type do you select? Windows Forms application, or WPF application?
Windows Presentation Foundation was introduced at the same time as Windows Vista, with final code released in November 2006 as part of .NET Framework 3.0. It was designed to replace existing Windows graphics APIs such as GDI and GDI+ with a more powerful, flexible and scaleable framework for buiding a graphical user interface, taking advantage of DirectX hardware acceleration and rich graphical effects. If Vista had proceeeded as originally planned, it would probably have been deeply baked into Windows itself, but in the end took a lesser role, presumably for performance reasons. Microsoft also added Windows XP support to make WPF more attractive to developers.
Another goal was to improve designer/developer workflow. WPF uses XAML, a declarative XML language, and is amenable to manipulation through a visual design tool. Microsoft released Expression Blend and Expression Design, which export XAML, as well as supporting WPF in Visual Studio.
Developing a Windows GUI can be frustrating. If you have ever wrestled with dialog units or the impact of "small" vs "large" fonts, you will know how badly scaling is handled. WPF is a huge improvement, with sensible layout management as well as great support for multimedia and effects.
Nevertheless, WPF was slow to take off. Issues included the large memory footprint of a WPF application, deployment of the latest .NET runtime, and lack of pre-built components; in fact, for a long time Microsoft itself advised against using WPF for line of business applications.
There was another factor too. Long-term Microsoft platform users have learned to be cautious about any technology that is not much used within Microsoft itself. WPF was a great example, with little obvious use beyond the Expression tools themselves. In this context, it was fascinating the hear the talk from Principal Software Engineer Paul Harrington at PDC in November, about how Visual Studio 2010 has been rebuilt with WPF. Harrington's team has an advantage over most of us, in that they can press the WPF team to fix bugs and make changes, and that is exactly what happened. Visual Studio needed to use invisible windows for some operations; WPF did not support that, but now now in version 4.0 it does. The text rendering in the new editor was making some developers feel physically ill, apparently, because of its blurry appearance on some systems, so a new text stack was built, enabled by turning off ClearType. The Visual Studio team ran into problems with focus and activation, and new modes have now been added to WPF to fix them.
My guess is that the stress-testing of the Visual Studio team combined with other improvements in WPF, such as new business-oriented components, will make it the sensible choice for a Windows GUI application, other things being equal (which they never are), once Visual Studio 2010 is released.
The big caveat is that developing new applications using a Windows-only API does not look like a smart choice in many scenarios, though it could still make sense within some organisations, or if your application is strongly hooked into Windows anyway. WPF has good support for new Windows 7 features, for example. But Microsoft is also releasing Silverlight 4.0, which has considerable compatibility with WPF but runs on the Mac as well as on Windows, is easier to deploy, and which fits with the web model for data handling. Silverlight 4.0 now has COM support on Windows, when run out of the browser, which means you can add native code if you really need to, and integrate with other applications such as Microsoft Office.
In some curious way then, WPF is maturing to become an excellent development framework at just the wrong moment. Nevertheless, I'd now think twice before hitting the Windows Forms option on a new application.
I'm just back from Microsoft's Professional Developers Conference in Los Angeles, where the star of the show was the latest update to the Silverlight browser plug-in that lets you run .NET applications cross-platform and within the browser. The pace of development is remarkable. It is only 9 months ago that we were first shown the beta of Silverlight 3, at the Mix conference in March. Silverlight 3 was fully released in July; and now we have version 4.0 beta, with release promised for the first half of 2010.
It is a big release too. Many of the top Silverlight feature requests are being implemented, including printing, right-click and mouse wheel support, a rich text control with editing, clipboard support (though text-only in the beta), drag-and-drop, interaction with Webcams and microphones, multitouch control, improved just-in-time compilation for faster performance, and improved databinding for business applications.
In addition, the forthcoming Visual Studio 2010 is the first to have the kind of Silverlight development tools you would expect, with a true visual design surface and drag-and-drop data binding. On the server, WCF (Windows Communication Foundation) RIA Services simplify the effort of authentication, talking to data, and integrating with ASP.NET.
Another notable feature is the ability to run a Silverlight application out of the browser, started from a desktop shortcut and displayed in a custom window. New in version 4.0 is an HTML control, which embeds IE on Windows and WebKit (used in Safari) on the Mac. These are desktop/web application hybrids. Silverlight 4 blurs the boundaries, by adding a new trusted mode. Subject to the user passing a security dialog, a trusted out-of-browser application gets local file access to user data, cross-domain network access, and on Windows native code interop through COM automation.
The snag with this last point is that any Silverlight application which uses COM automation will only run on Windows, breaking the cross-platform compatibility which is a key reason to use Silverlight in the first place. Although Microsoft says the feature has been put in simply to meet the requirements of a few Enterprise customers, it seems to me that it goes well beyond that, making Silverlight viable in many scenarios that previously would have required a native solution.
Microsoft's ideal scenario is one where applications run everywhere, but run best on Windows, preserving its desktop lock-in. The company calls this "lighting up the platform"; but Windows is somehow the only platform that gets lit up.
I still think it is time to learn Silverlight. The reason is not only Microsoft's signposting of this as its key technology for future client development, but something else I saw last week: Google's Chrome OS. I'll be writing more about this; but I was impressed by how this forthcoming browser-based operating system promises to solve long-standing problems: cheap, lightweight computers that are secure, that start up instantly, that give us access to all our data, but can be left in the back of a taxi without compromising our secrets.
What if Chrome OS catches on? Does Microsoft become irrelevant? The real world does not move that fast; but considering the continuing popularity of the Mac along with the prospect of Chrome OS, it strikes me as brave to presume a Windows-only client for future development. Silverlight on the other hand should run in Chrome OS, either using Mono's Moonlight, or the Intel port being done for Moblin, or perhaps Microsoft itself will have to dirty its hands with Linux. Google might block Silverlight - it was non-committal on the subject at the Chrome OS press briefing - but I'm guessing that concerns over appearing excessively controlling will trump the desire to shut out a competitor.
The point here is not that Silverlight is the answer for all client development; there are plenty of other strong choices. The point rather is that for Microsoft platform developers Silverlight is the technology that makes it possible to take your C# or VB.Net skills and transition them to a new cross-platform, web-oriented world.
At Microsoft Tech-Ed 2009 in Berlin long-time Windows server expert Mark Minasi gave a session on the .vhd format used by Microsoft for virtual hard drives in Hyper-V, the virtualisation feature built into Windows server 2008.
Minasi's talk was not about Hyper-V, but rather about other things you can do with a .VHD. He even noted that in a Windows environment you can use a .VHD as a superior form of ZIP (though without the compression), if you want a single file that can contain windows files and folders while preserving NTFS security attributes, and that can be mounted - or "attached" in .VHD jargon - rather than having to be extracted elsewhere.
One neat trick is to use .VHDs for multi-boot. Multi-boot is less important now that virtualisation works so well, but can still be useful if want to test an operating system with full performance and access to hardware such as accelerated graphics. The old way to do this is with multiple partitions, but this is somewhat inconvenient. Windows 7 is able to boot from a .VHD, and you can set up mutiple VHDs so that you can choose which one to use at start-up. There are a couple of limitations. The operating system has to be Windows 7 or presumably 2008 R2 (which uses the same kernel); and sleep/hibernate does not work in this configuration.
A VHD is still just a file, so you can back it up by copying it elsewhere, provided it is not the one currently running. Note that in this configuration only the hard drive is virtual, not the computer hardware, so while you could go on to mount the VHD in Hyper-V it would be like moving Windows to a new motherboard and very likely would not boot.
Another clever tip is that Windows 7 setup support a keystroke combination, Shift F10, which gives access to the command line for MinWin, the cut-down version of Windows that runs during setup. Here you can get access to Diskpart, the command-line disk management tool, which among other things lets you create a VHD. So you can take a machine with an untouched hard drive, boot into the Windows 7 setup, shell to the command line and create a VHD, then attach and install Windows onto that new virtual drive. Setup actually states that this does not work; but it does work, and we saw it demonstrated.
There are three kinds of VHDs. A fixed VHD has the same on-disk size as its capacity. An expanding (or dynamic) VHD reports the size that you specify when it is greated, but only occupies the space on its host that is needed by the data written there. This is convenient for backup, and lets you over-commit the host drive if you choose to. The third kind is a differencing VHD - a VHD that is based on a parent and only occupies the space needed by its difference as you write to it. The GUI Windows disk management tool does not support creation of differencing VHDs: one of Minasi's points is that you should learn the command line approach using Diskpart in order to get access to all the available features. That said, differencing VHDs are supported in the Hyper-V GUI management tool.
The bottom line is that VHDs have uses that go beyond virtual machines and if you work on the Windows platform it is well worth becoming familiar with them.
At the Future of Web Applications conference earlier this month I spoke to Microsoft's corporate VP of the .NET Developer Platform, Scott Guthrie about ASP.NET MVC. Guthrie is a co-inventor of ASP.NET along with Mark Anders, now at Adobe. A few months back I wrote a piece entitled ASP.NET MVC rescues Microsoft's web platform, but I wanted to hear from Guthrie how he sees the framework evolving, and to explore whether it is time to abandon the older Web Forms approach. How does he see the future of the platform?
"The amount of buzz and religious fanaticism about [ASP.NET MVC] is amongst the highest I've been involved in, certainly since .NET 1.0 and Silverlight. Some people prefer the Web Forms model and I emphasise that Web Forms is not going away, there's all the new stuff that's coming for Web Forms 4.0.
"MVC is an alternative way to do UI and still leverage ASP.NET. For crowds like the one here at FOWA that wants total control over the markup, and who like test-driven development, it's a dream framework. Those folk tend to be more online, so they communicate better which is part of the reason you hear the buzz. I think we'll have more than a million developers using ASP.NET MVC within the first twelve months."
In your talk you mentioned the stackoverflow site which performs very well but runs on not very much in terms of hardware? Is ASP.NET MVC more efficient than Web Forms?
"ASP.NET itself has always been really fast, we've had a lot of success with large sites. One of the things people like about ASP.NET MVC is that the model fits to what they are expecting, for the large LAMP contingent which is heavily represented at this conference. And when they do the performance testing they say 'Holy cow, this thing is fast.' Stackoverflow is a great example, written I think within three weeks and scaling to that level with two machines. Performance is a feature, and one of the reasons StackOverflow works as well as it does is that it's instantaneous response time.
"Conchango just did a site, implemented in 20 weeks, a giant ecommerce project, it's 100% ASP.NET MVC. The SEO is phenomenal, the YSlow rating is phenomenal, they're just blown away. It was fun talking to them last night - the guy was jokingly saying, 'I can't believe it works so well'. It's like the best marketing literature in the world times ten. More and more when I give talks I'd say half the people are new to ASP.NET MVC, and the other half come upand say, 'by the way we've done five sites on it.' That's great to hear."
On equivalent hardware and leaving aside different coding styles, is ASP.NET MVC going to scale that bit better than Web Forms?
"No. The reality is you can build hugely scalable sites with each. Where it does help a little bit is that there is smaller page size and there's a bit more control. There's less abstractions."
And the page lifecycle is shorter?
"It is shorter. I don't think that's making any measurable perf difference. It's more that it naturally flows to what they're doing. I do think it's fast, in the same way that web forms can be fast too. But it promotes a certain way of working that, if you know what you're doing, you tend to build really fast apps."
What about the open source aspect? Are people contributing code?
"People are not contributing code directly to ASP.NET MVC, but we're shippling JQuery and we're shipping JQuery validation which are open source projects, and we are integrating them into our code. With JQuery in ASP.NET MVC version 1.0 we just shippped it, whereas in version 2.0 we have helper libraries that are making big usage of it.
"I'd say that's a first for Microsoft, we're actually taking open source software that has multiple contributors, and using it in a deep way within our own product.
"We ship the ASP.NET MVC source code under an OSI Licence. You can take the code, you can modify it, you can do builds. I know a few people that have done customer tweaks, but for the most part it's that people like being able to learn the product through the code. There's also the reassurance of knowing that if they ran into something, they could fix it."
Would you consider accepting community contributions to the code?
"We've thought about it. I think a lot of people interpret open source as 'hey, anyone can just submit stuff'. The reality is that pretty much every open source project has a closed set of contributors. They come from multiple organisations or backgrounds, but you don't check anything into the Linux kernel without Linus or Andrew signing off on the fix. That would be true of ASP.NET MVC, in that there would be a core set of contributors. At some point I think we will probably open it up to let people to contribute code, or at least patches."
What's new in the latest ASP.NET MVC 2.0 preview?
"The ability to easily do forms validation for input, server-side and especially client-side in a very declarative, easy way, is a huge productivity win.
"'Areas' provide a way to take a large project and easily structure it into multiple small projects.
"New form helpers and what we call editor and display templates for customising them is an innovative way to get strong typing, intellisense and debugging support, and a lot of flexibility in terms of UI generation.
"Asynchronous controllers allow you to call call services on the web, the Twitter, the Facebooks of the world, and much more efficiently scale your web server. The classic problem if you're calling Twitter is what's the response time of Twitter? What's the response time of Facebook? Most web servers are multi-threaded so they're processing multiple requests, but say they have 10 threads running and 15 requests come in, and each of those requests need to go and access Twitter, you're going to block 5 people while nothing is going on on the server. With the Async support we provide a way that you within your app can say, I'm going to wait for a while, yield back the thread, and when the data comes back reschedule me. It can dramatically improve the scalability of the site.
"We're doing a bunch of work around helpers for caching, paging, and a other things. In general it's a compatible release, we're trying to listen to the community, keep it a very transparent, Agile-based development process and knock off the top asks.
"We ship the source to every preview, take lots of feedback. That's the other thing people have really liked about the project, this open feedback. They don't feel like we're telling them, here's the way it is, take it or leave it. They like the fact that we've been iterating with them."
Guthrie is diplomatic about the question of Web Forms versus ASP.NET MVC, and even though I pressed him, would not quite agree that it performs much better. Clearly Web Forms is not going away. Take a look though at some of the comments from practitioners like Howard van Rooijen of EMC (formerly Conchango):
One of the great aspects of ASP.NET MVC is how lean and clean the architecture is - there is so little background noise compared to WebForms; possibly the best illustration of this is the difference between the MVC Request Pipeline vs. WebForm Page Lifecycle. The number of hoops you are forced to jump through in WebForms, compared to MVC is quite staggering.
Overall I heard nothing to change my general opinion, that if you can use ASP.NET MVC rather than Web Forms, you probably should.
Mobile devices are today's development battleground. Timing is everything: I recall Borland's 2003 conference when it introduced an extensive mobile development strategy based on the ill-fated C++ BuilderX, with SDKs from Nokia and Symbian. The sessions drew sparse attendance and Borland later abandoned the product, returning to the Windows-oriented C++ Builder.
So what changed? In part, devices have become more powerful and mobile internet access faster and more pervasive, making the platform more attractive. A bigger factor though is Apple's iPhone. In hindsight, the mobile vendors and operators made mobile development too difficult, with fragmented platforms and locked-down devices. Microsoft has had some success extending Windows to mobile devices, for enterprise development in either C++ or .NET, but its market share is too small, the devices insufficiently well liked, and the deployment obstacles too great. Java had some success too, but write-once, run anywhere never really worked for mobile.
Enter iPhone, with a single platform and easy deployment through the App Store. The "easy deployment" part has to be qualified, since developers have been confronted with limited access to the device, restrictions on what they can develop, and an opaque approval process; but it has worked, and the potential of the mobile platform - about which we have known for years - is now being unlocked.
Other vendors are belatedly rising to the challenge. I'm just back from Nokia's Qt Developer Days, and saw the energy the company is putting into creating a cross-platform, open source mobile development framework. Windows Mobile, Maemo and Symbian are on the immediate roadmap. On the deployment side, Nokia has the Ovi store. I've also been at Adobe's MAX in Los Angeles, where broad mobile support for the Flash runtime was the big story. The Flash runtime is not coming to iPhone yet, but Adobe has a native compiler for Flash applications which targets iPhone. Adobe also has app store plans. Google Android is another platform where all the pieces are in place, and Palm Web OS a new hopeful on the scene.
This means developers now have numerous choices for mobile development, as well as more pressure to create or extend applications to embrace mobile clients. It is not an easy choice. An AJAX application will work on the iPhone and elsewhere, but there is no offline support or access to device features, and the capabilities of mobile browsers vary greatly - though Webkit is becoming a standard on non-Windows devices. Native iPhone works great on Apple's device, but nowhere else. Flash is becoming interesting, but devices with 10.1 will not be around until next year and it is an unproven platform in a mobile context. Windows Mobile will trudge on, though Microsoft's mobile story seems particularly incoherent at present and I expect declining market share. Java on mobile has not gone away either; and Google Android is pretty much a Java platform. C++ will always be attractive for lean, fast applications.
It is fun to pick winners and losers, but impossible to tell how all this will shake out. Here's two safe bets. The first is that mobile, internet-connected applications are in many ways the future of the client. The second is that focusing on a strong web services API (of whatever flavour) is the right place to start. What's your mobile strategy?
I attended a round table to discuss the use of open source software in government, with Red Hat, Ingres, Alfresco, and on the government side representatives from the Office of National Statistics and Islington Council.
It is a fascinating topic on several levels - and not just for government. The two big questions: first, what is the rationale for prefering open source; and second, if you are convinced of its desirability how on earth do you get a huge, diversified entity like the UK government to increase its adoption?
There is clearly some kind of disconnect. The government already has a policy which stops short of mandating open source, but does say:
Where there is no significant overall cost difference between open and non-open source products, open source will be selected on the basis of its additional inherent flexibility.
In other words, given two otherwise equal proposals, open source is favoured - yet in practice we were told that 95% of software in use in the UK government remains proprietary.
So why is that? There are dozens of reasons. It's the available skills, with armies of experts in Microsoft, Oracle, IBM, and so on, compared with only a few willing to specify open source technologies. It's the culture, with countless existing supplier relationships and a well-trodden procurement path with the usual suspects. It's the existing envirnonment: if you start from a point where the servers are Windows, say, and the desktops all have Microsoft Office, it feels more comfortable to continue down that path. It's the lock-in, especially when it comes to things like proprietay SQL extensions and stored procedure languages, that simply do not port easily to new database managers. And it's canny vendors, who go for site licences with the widest possible scope, so that if a small group decides to break the mould and use something different, it looks more like a cost than a saving - because they are already licenced for the proprietary stuff.
These are tough obstacles to overcome. Put another way, the rationale for adoption has to be exceptionally strong to overcome the inertia; and it was here that I found the round table unconvincing. The open source companies gave diverse reasons for the benefits. Lower cost was mentioned frequently. By contrast, John Powell, President and CEO of Alfresco, talked intensely about how the UK was somehow handing over its soul to silicon valley, by not building up local skills in open source software. Someone else said how nice it was that open source software was free so that everyone in an organization could use it; another gently observed that since most open source companies make their money from support agreements that are per user, this is often not the case.
The most persuasive rationale is that open source software tends to support open standards and therefore avoids lock-in. This lowers long-term costs, by ensuring that the customer always has freedom to switch.
The snag with all these arguments is that the proprietary companies can counter them easily. They will reel off all the open standards they support. They will draw graphs showing how much money you save by using their stuff. They will point out that those with skills in their technology can easily market them worldwide. The outcome is that nothing changes.
I don't doubt that leading vendors make excessive profits on software that should be commoditised and cheap, or that vendors follow strategies designed as much to keep us hooked on their stuff, as to advance technology for our benefit. It's a cycle that needs to change.
At the same time, the open source vendors have to recognize - and to be fair, I reckon they often do - that most of us will not switch for ideological reasons. We want to get our work done. The best open source projects, things like the Apache web server (if there is anything like it) succeed on sheer quality and reliability, not merely through being open source.
The tough question: does the open source ecosystem have sufficient resources to deliver that quality, against proprietary vendors with huge profits to pour into research and development? There are plenty of decent open source products; the number that are truly best of breed is more limited. Currently it is the big proprietary vendors that have the advantage.
I left the table with more questions than answers. Should governments introduce more draconian legislation, to counterbalance the industry bias towards the status quo? Will the move towards cloud computing break the pattern? Should legislation be focused on mandating standards support, or even that applications should be proven to work on two different platforms, rather than the matter of open versus closed source? If today's MySQL is tomorrow's Oracle, is there really any difference? Isn't there too much to worry about already, solving problems and delivering successful projects?
If pressed, I would always incline towards the best technical solution, rather than one which ticks boxes, even open source boxes. That said, we are all susceptible to being bamboozled, not even looking at open source alternatives if we already know a proprietary tool or component or platform that will do the job. Even for individual developers, it makes sense to choose the open source solution in cases where other things are equal; and to think twice before building vendor lock-in into the applications we create.
