Recently, Microsoft announced that is has joined the Linux foundation, that SQL Server is now ready for testing on Linux and a preview for Visual Studio on Mac is available. This is a transformation that cannot be underestimated. They reinforce the direction that Microsoft CEO Satya Nadella started a couple of years ago. And they are the right things for the company to do.
HP announced that it will make WebOS an open-source project, and expects to make new hardware to support it sometime in 2013. What hasn’t been determined is what licence they will use, and that determines how “open” it will really be. Ideally, it would be either a GPL-type licence or a BSD/MIT-type licence, allowing some degree of latitude for developers. It could, though, end up with more a more restrictive “shared source” licence like Microsoft’s typical approach. What I don’t expect is that it will be like Android’s “open” licence, in that some releases are only available to select licensees prior to general availability (much like new major releases are only available to a particular handset maker until the device is released), given that HP is likely to be the sole hardware manufacturer for the short-term.
Is this a good idea? Sure it is. Let’s face it: the Palm assets aren’t worth all that much, and there aren’t an enormous number of buyers for yet another mobile operating system. Consider, too, that RIM may come up for sale, and any players looking to get into the mobile market may be holding their breath to see when RIM and the Blackberry assets become available. I would expect the thinking is that a company with more than zero market share is more tempting than one with none.
An open source future for WebOS may give it an outside chance at a long-term future, and a potential seat at the mobile table. For now, the world has consolidated around Android and iOS, and going up against them is going to be very, very hard for the next couple of years. But, the longer-term is still uncertain, and there is no guarantee that the mobile space is going to shape up like the PC space. The success of Linux in the server room may act as a motivator here: it came out of nowhere a decade ago, and now can claim 20-25% of the overall server market, and as much at 60% of the space for servers facing the public (web servers, DNS servers, mail servers). But, there is a cautionary tale here: Linux has made virtually zero impact in terms of desktop share, primarily because it lacks one key ingredient, Microsoft Office, which would allow it to play in the PC space. A similar challenge faces WebOS: without a viable ecosystem, any technological or cost superiority (real or perceived) is moot.
To succeed, WebOS would need to find a way to not only build a rich ecosystem, but provide some means for people to switch for minimal or no cost. Smartphone and tablet users, particularly iOS users, are investing a lot of money in their apps and content. Leaving iOS means abandoning some or all of that investment. It may not be necessary to give all of the replacement content for free, but offering discounts (like some way to repurchase the WebOS version of an app for really, really cheap) might make it easier for people to switch over. What we probably won’t see is the “I have to upgrade, so why not buy something new” that is likely helping MacOS. Unlike on the desktop, upgrades to apps are generally free (there are exceptions, but those are pretty rare). For a PC users, if they have to buy an upgrade to Office, or they want to buy new games that are available on both Windows and MacOS, moving to the Mac isn’t as big a deal, cost-wise, because they have to spend the money anyways (buy/upgrade software for their current PC, which needs replacing anyways, or buy a new Mac along with the replacement software). Buying what amounts to a perpetual, lifetime upgrade takes away that opportunity for change.
The other question mark is the tablet space. It is only about 2 years old (ignore the Windows Tablets, they didn’t sell enough to even mention), and while the iPad is still far ahead in terms of sales and marketshare, the landscape is still in flux. The recent arrival of the Kindle Fire may have an impact, and in the short term I fully expect it will. What will remain to be seen is if the Fire’s initial enthusiasm has momentum, and if the Fire is a device that people buy exclusively, or if it is one they buy to augment their iPad. There are a lot of iPad owners with regular Kindle eReaders, so it may shape up that there are lot of people who buy the Fire alongside, rather than instead of, an iPad. The key for any new tablet is, again, ecosystem: apps and content. Either that, or really, really cheap (witness the success of the TouchPad fire sale).
In the end, though, HP has nothing to lose and more to gain by making WebOS open source. It may be enough to encourage developers to experiment and build apps for the platform. There may be handset makers out there that want some freedom from Google and Android (from what I’ve heard, it isn’t all roses and sunshine for the handset manufacturers), but don’t want to build their own platform. An open source WebOS is a long-shot, in terms of success, it has a non-zero (but very small) chance. Shutting it down and writing it off would have reduced that chance to zero.
A posting on the Inferno Development blog outlines their assumptions about 5 reasons why corporations “fear open source”. It offers some of the usual pablum about how many corporations “don’t get it” or make bad assumptions based on bad data. The authors also seem to assume that these “fears” are somehow unique to open source. The problem is that these 5 points are more about any significant technological change in a corporations infrastructure, and whether that change is from a closed-source product to an open-source product isn’t the issue. The main issue is change itself. The 5 points in the article are:
- Fear of rising costs: the assumptions that “corporations” think that going open source will cost more than going some other direction
- Fear of time loss: that time will be lost during redevelopment of some systems
- Fear of cheap products: that corporations may think that open source is somehow inferior
- Fear of technical problems: more specifically, what happens if something breaks
- Fear of changing culture: that moving to an open-source product will cause people to leave, or become less productive or not enjoy what they do
These 5 items are not unique to open source. These 5 are real, proven issues when moving from any technology that you already have to something different. Some of the author’s assertions in trying to debunk these fears are actually incorrect, or at least least a little off-target.
Fear of rising costs: no matter what you change a system to, there are costs involved. I don’t care if its moving your graphic artists from Photoshop to GIMP, or moving your group communications from Lotus Notes to Microsoft Exchange. If your end-users are already trained and comfortable using a particular technology or system, you will have to spend time and money to retrain them on the new system you’ve selected. Your internal IT staff will have to spend time and effort learning how to install, configure and run whatever it is you have selected, whether it is open source or not. On top of that, I’m not convinced that using an open source tool has any faster learning curve than a closed source one. Take GIMP vs. Photoshop as an example. While there are some books and training on GIMP, there are many, many more books and training courses available on Photoshop. I am more likely to find someone with Photoshop experience than GIMP experience. That doesn’t mean GIMP is bad, or is “scary”: it means that the available resources and talent pool is smaller for GIMP than it is for Photoshop. I am unlikely to select GIMP, simply because it will be easier to find people who know Photoshop, are comfortable with it, and can be productive right away. On the other hand, if I were to chose server technology, I am just as likely to select Linux as I am Windows, simply because I know that I can find people who are competent with either of them (or in some cases, both of them). There is an enormous amount of documentation available for both, a large body of contractors and consultants and plenty of training available. Going with either represents the same level of risk, from a cost and training point of view.
Fear of time loss: to imply that switching to an open source system requires little or no time and effort is naive. Consider switching databases. Moving from Oracle to DB/2 will take time, training and effort, just as a move from Oracle to MySQL would take. When you are moving from one system to another, you have to take the time to train your IT staff that support it, developers that use it, testers that test on it, etc. It doesn’t matter, and moving to an open source product isn’t somehow magically easier. As the author says “sometimes the open source software has better documentation”. Yes, and sometimes it doesn’t. It isn’t any different with open source than it is with closed source products: some have a wealth of documentation, training and experienced people available. Some don’t. To imply that open source is generally better is at best a guess, and to assume this is universally the case can be risky.
Fear of cheap products: while some corporations still think that ‘expensive means better’, most smart corporations don’t. They take a balanced approach, and select technology based on cost, capabilities of the vendor, and available resources. Personally, if I have to go with a low-risk solution. I would rather spend the money on a product from a vendor that will be around in the next few years, than select an open source solution that has just come out of beta and hasn’t developed much of a following. The risk of cheap, or more correctly shoddy/poor products, is probably about as good with open-source as with closed-source. With closed-source, I can run the risk the vendor is going to go out of business, or change direction and abandon the product. With open-source, it is entirely possible that no meaningful community develops around the system, or that the primary authors decide to abandon it or take it in some odd direction. Sure, I can get the source, but now I have to expend my time and money to have developers maintain the thing? Where’s the real savings in that?
Fear of technical problems: again, this is about risk management, and something being open-source doesn’t automatically make it more stable and less buggy, any easier to diagnose and repair, or any easier to obtain resources to deal with problems. Once again, it comes back to who or what is backing it. For something like Linux, I’m just as likely to get an answer and a solution to a problem as I am with Windows. Both have large communities of users (and in the case of Windows, Microsoft itself) to back them up, answer questions or potentially have already seen the problem I am having. However, if I pick some obscure open-source accounting system that is only supported by one developer part-time, and with a tiny user community, finding help to problems can be harder. There is one element where open source can generally not keep up: if you have a corporate requirement that a real corporation stand behind a licence and support agreement, then open source systems can be harder to adopt (if they can be used at all). I can’t sue a user community if something goes wrong. I can sue a corporation, and at least try to get compensation for any problems that arise. Not all companies need this (in fact, most don’t), but some do, and this is a very real concern that may have to be considered.
Fear of changing culture: the risk that you will anger your employees by changing systems is very real, no matter what type of system you switch to. If I have a community of users, and we’ve been using Lotus Notes, I run the risk of anger, alienation and frustration whether I move them to Thunderbird coupled with some other backend system, or whether I decide to move to MS Exchange and Outlook. Change is change, and people generally don’t like it.
The last point in the article comes as a side note, and that is one of licence concerns. I have worked with a few lawyers now who are very well versed in the various aspects of different open source licences like GPL, LGPL, etc. They have concerns, some legitimate, about what using open source does to the rest of the business. In some cases, great care must be taken to ensure that using something open source doesn’t put a burden on the rest of the business. As with the 5 “fears”, its about managing risk and knowing that there could be consequences. This isn’t irrational, its business.
The reality is these “fears” exist no matter what type of technology you are talking about. To think otherwise is naive in my mind. Open-source is neither good or bad, it just is, and deserves as much consideration as closed-source solutions. Both must stand on their merits, and meet the risk profile associated with the organization that needs or uses the technologies. Open-source isn’t something to fear, but neither is it some panacea free from risk and problems. Do your research and due diligence, and caveat emptor. Free isn’t always free, but expensive isn’t always better. As with anything, the answer is “it depends” and you go forward from there.
I have been involved, in the past, on projects where technologies were added simply because someone wanted to. There was little or no review of the implications of adding technology at will. The result was demonstrable issues with maintainability, stability and the ability to learn the system. On projects where the senior architects, along with management, kept a tight rein on what is added, the results were simpler projects that were easier to work on, easier to learn for new team members, and easier to maintain and extend. It can be tempting to add new technology, either because it is “cool” or because of some perceived benefit (sometimes based on little or no long-term evidence). However, generally speaking, less is better.
Adding new tools or technologies has a number of implications. While the most obvious is complexity (because it is yet another technology to learn, to integrate and to maintain), there are others that are often overlooked.
Additional complexity also adds to the cost of the product, in different ways. The software itself may be free, but time taken to integrate and maintain, without offsetting benefits, is money spent that could have been spent elsewhere. For commercial software, you have to add the additional cost of the licencing and maintenance. When selecting technology to add to a project, you need to understand the cost (and nothing is ever free) and compare that cost to savings you can (or cannot) expect over the long haul by using it.
Many technologists forget to understand any legal implications for adding new technologies. A careful review of the licence (if possible, by qualified legal counsel) can avoid all sorts of ugly problems in the future. On occasion, a licence can restrict what you can and cannot do with your product. It may open you up to legal action (for example, in potential patent violations). This isn’t typically a problem, but the legal aspects of a new technology’s licence needs to be as carefully reviewed as the technology itself.
Adding additional technology also adds a new dependency on someone else’s release schedule. If you require additional features or changes for your product to work better (or properly), your project can now end up with an outside 3rd party on your critical path.
You also become dependent, quality-wise, on their technology as well, particularly if the technology is a core element of the system. If their quality starts to deteriorate, then so does the quality of your own system. Related to this, your responsiveness to your customers is now dependent on how responsive (or not) the vendor is. If you have selected technology that is core to your system, there is no point in promising 1-hour response time to severity 1 problems if the vendor only promises same-day turn-around on the same severity of issue.
The last dependency is on the future features and direction the product takes. By giving up some control to a 3rd party, you put your product at their mercy, and if they choose to start in a different direction, you may find your product depending on features or functionality that is no longer supported, or not supported as well as you need it to be. In addition to future direction, for commercial products, you are dependent on their future success, and you can find yourself using technology with no company behind it if they go out of business.
Some of these dependencies can be mitigated with open source technologies, if only because you at least can get the source code and take over the care of feeding of it should the community decide to abandon it. This is not always an option for commercial software.
This isn’t to say that adding 3rd party technologies is bad, and that you should build everything in-house. What this means is that, before just adding any technology, some care and due diligence is needed before it is added. Adding technology because it looks “cool”, or because someone claims it can make things faster/better/easier, isn’t good enough. The technology should be evaluated based on its technical claims. The costs associated with it need to be compared to what can be saved. A legal review of the licence should always be conducted to avoid future problems in that area. Adding 3rd party technology often makes sense, but you should confirm it makes sense before committing yourself and your product to it.