Slashdot Mirror


Is Open Source too Complex?

Jason Pillai writes to tell us ZDNet is reporting that at last month's Microsoft Worldwide Parter Conference in Boston Ryan Gavin, director of platform strategy, claimed that one of the big downsides to open source is complexity. From the article: "Gavin noted that the flexibility of open-source software in meeting specific business needs also means systems integrators and ISVs have to grapple with complexity costs. 'It's challenging for partners to build competencies to support Linux, because you never quite know what you're going to be supporting,' he added. 'Customers who run Linux could be operating in Red Hat, [Novell's] Suse, or even customized Debian environments,' he explained. 'You don't get that repeatable [development] process to build your business over time.'" More than once I have had complaints that my setup is more difficult than necessary. Is open source really that much harder, or just different than what most are used to?

3 of 356 comments (clear)

  1. Eh? by bloodredsun · · Score: 5, Interesting

    Sorry, but I read this as "Choice is confusing - stick with what you are comfortable with. Hey look, that's us!"

    This sort of gibberish is what you would expect from the most popular product in the market who are being challenged for the first time in a while.

  2. Short answer: depends on the user. by Noryungi · · Score: 5, Interesting
    Long answer:

    Is open source difficult? Yes, if you are just an average user. No, if you are a system administrator-type of user and that you manage information system for a living.

    If you are just an end-user, someone who uses computer to do something else (creative work, accounting, marketing, sales, whatever) and you don't know anything about computer, then yes, I guess Open Source is still too difficult for you... unless you have a sysadmin close at hand to (a) install your machine and (b) make sure it's updated regularly. Then, Open Source can be -- should be -- just as easy (if not easier) than Microsoft products. Open Source GUIs, such as XFCE, KDE or Gnome, once installed and configured properly, are just as easy and friendly as Windows. Of course, the ultimate in user-friendliness is Mac OS X, but that's another story.

    Please note that the term "user" -- as used above -- is not negative at all in my mind: I can perfectly understand that your job has nothing to do with computers, and that you don't have the time, or the inclination, to learn more about computers. And no, I don't think there is such as thing as a "Power User". Either you know enough to manage your own machines, or you don't. People who know just enough to be dangerous, but not enough to clean up the mess they have made, are users in my mind. Dangerous ones, but users nonetheless.

    On the other hand, when it comes to system administrators, Open Source wins hands down. Things like Apache, vsftpd, NFS, CUPS, perl/python/shell scripting and, especially, OpenSSH make my life (and the lives of countless other people) so much easier than their Microsoft counterparts. Plus, they are a lot cheaper than all the Microsoft products, they are more reliable, easier to manage, upgrade, patch and install. Seriously, consider the following examples to upgrade a machine or an application:
    1. Debian: sudo apt-get update && sudo apt-get upgrade
    2. Slackware: sudo upgradepkg ./*.tgz
    3. OpenBSD: sudo pkg_add -u -vvv -i
    4. Etc...


    Sure, to get to the stage that you actually can type these commands under OpenSSH and know what they do, you need to put in a lot of work. But the result is worth it. And, if you are a sysadmin worth his/her salary, you'll probably have a passion to learn that kind of things. Once learned, these commands result in less downtime, less cost, more customer satisfaction and a more efficient company. All in all, Windows, with its lack of security, Registry Database, its rather ugly GUI and its general flakiness is not good enough or "simple" enough when it comes to systems that must run 24/7 and support dozens, or even hundreds of users.

    Linux, on the other hand, may not ready just yet for the desktop. But it will one day. Which is probably why there is an un-ending stream of FUD coming out of Redmond these days...
    --
    The right to offend is far more important than the right not to be offended. (Rowan Atkinson)
  3. Re:All Software is complex. by swillden · · Score: 4, Interesting

    It does make it more difficult for a large company to develop for a Linux crowd in general.

    Somewhat, but it's not that bad. I wrote a commercial, closed-source Linux app that had to run on multiple distros and it's really not that much of an issue. The app I built was one of the more difficult ones to support across distros, too, since it had to integrate with (or replace) the login process, screensaver, etc. These are areas where distros do things very differently. Normal applications have many fewer issues.

    Some things I learned:

    • At core, all major, modern Linux distros look the same. There are small differences in they way files are organized and larger differences in how packages are installed and managed, but these differences don't require much effort to work around, even when you're changing the most distro-specific elements of the system (boot processes, login processes, etc.). Liberal use of configuration files and glue scripts is a very good idea so that you can reconfigure for lots of different environments without changing the binaries.
    • Cross-distro development is easy. Cross-distro packaging is fairly easy. The hard part is the cross-distro testing, not because it's particularly difficult, but because you have to do it on every distro you're going to support. It's well worth automating as much of the testing as possible. I recently began trying to use a test-driven development process, and I wish I had used it on that Linux project.
    • Although it's possible to create a cross-distro installer, your customers will be much happier if you provide native installers that integrate properly with their package management system.
    • You cannot expect to make a single RPM package for all RPM-using distros. The RPM SPEC files won't differ hugely from distro to distro, but they will differ if you want seamless integration.
    • For a corporate app, you really only need to target a small set of Linux distros to cover nearly all of your market. Red Hat, SUSE and Debian cover it. In the case of Red Hat and SUSE you need to support both the current release and the previous release. For Debian/Ubuntu, it's less clear. Ask some customers and take a guess (and see my next point).
    • You can treat the too-many-distros problem as an opportunity. In my case, I recommended that we do three things: First, create packages that cover 95% of the target market. Second, provide a tarball with all of the binaries and some instructions on how configuration files need to be set up so that very technical customers (common in the Linux market) can figure out how to integrate it into the distro of their choice -- with the caveat that you will only support them in resolving issues they can reproduce on a supported distro. Third, (here's the opportunity part), offer to make it work in whatever distro they like, for an integration fee. Charge them enough that you can do a thorough job, including writing all of the automated test code for that platform, all of the documentation needed by your customer service department, etc., so that you can just add it to the list of "supported" distros, and make a profit doing it.

    Really, I think the biggest difficulty with selling commercial Linux apps is the relatively weak demand. Although I don't like Windows, it's still quite dominant, and Windows apps are almost guaranteed a larger market. If, however, you can find a niche where there is significant demand for a commercial Linux product, the multiple-distros issue isn't going to significantly increase your development cost, will perhaps double the cost of developing you installation packages, and (assuming you make good use of automated testing) will probably increase your testing costs by 10% or so. Net, I'd say it costs <5% more to develop a significant application for multiple Linux distros rather than just one distro.

    --
    Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.