?

Log in

No account? Create an account

Speaking of poorly written articles on understanding open source...

« previous entry | next entry »
Apr. 14th, 2007 | 10:55 pm

Dirk Riehle has posted a paper on the The Economic Motivation of Open Source Software: Stakeholder Perspectives.

Let us take this article apart.


..should use open source software to grow their user communities and build an ecosystem around their products and services..


A good product is a good product. If we look at this from the stand point of the web has Livejournal been any more successful then Google because it open sourced its framework? I don't think so. Both exist because they delivered value. I've never been sure about why Brad open sourced LJ in the beginning but I don't believe it was because he thought the masses would contribute in mass to its evolution (and I speak as someone who has sent in patches and have had them accepted in the code). Open source had little to do with either of the products success with users, their success was more that the creators got out of bed in the morning and put effort into what they were doing.


Community open source is... Commercial open source is


There really isn't a real difference here. One might have a foundation and the other might have an LLC. What both have are a set of individuals that drive the code forward. The makeup of the organizations are really immaterial, what matters it that there is someone, or some group, who makes decisions. Open source is about as far as you can get from "group process". All successful open source projects have a driver or a set of drivers. Find the drivers and you find out where the project is going. In this regard there is no difference between open source and closed source, the only difference is that a disagreement can lead to a fork, and that is the best for all possible parties.


Eric Raymond notes that developers contribute to open source projects for the personal gratification that comes from increasing their reputation among peers


Can we dispense with this myth? Yes, there are some developers who do this, but I have never met a major contributor who found this motivating. I once posed this question to Monty and his response was "we did it because we thought we could get more customers for our consulting". You don't reach fame by contributing to a project, you reach fame by creating a project. Fame though is a pretty poor motivator for doing anything innovative.


a system integrator's interest to acquire hardware and software as cheaply as possible


This is a half truth, it is in the system integrator's interest to have to do as little support as possible. Creating the product is a cost, but the real cost is supporting it. Legacy, bad versions... it all adds up eventually. If you create a product with a high demand, but is lousy engineering, you will burn up all the cash you make in supporting it.


Switching from more expensive closed source software to less expensive open source software increases the profits of a sale..


This is another half truth. Yes it looks great to switch to a cheaper component to make the cost of deploying your product cheaper, but the integration costs will eat you alive. I've never recommended someone pull out Oracle from their main business application and install MySQL. It does not makes sense. MySQL doesn't work the same, and it won't perform the same. What do I recommend? When you rewrite your application, then think of MySQL from the beginning.

I once saw a customer pull MySQL from their environment and install Oracle. It cost them millions, and in the end they just kept using MySQL in other environments so their over all need for knowledge never went away. I've also seen the opposite be true as well.


In a closed source business, most of the investment in new software comes from shipping the first copy.


And open source appears from thin air? The author goes on to talk about shipping your first CD, which is ludicrous, since shipping a CD means you are pushing your product into a retail channel. Those channels went away in the 90's, along with the stores who made their money being a part of that channel (the exception being the Video Game market). The Channel is the internet, and the cost for setting up a website to distribute your software is tiny. Open source or closed source, someone has to write the software in the first place.


Unlike community open source, however, one company controls commercial open source.


This doesn't even begin to be true, and it makes me wonder if the author understands the GPL or how software springs up around projects. If I use MySQL as an example there are at least three different individuals who create their own versions of MySQL. Sasha has been doing this for four or so years for now. He customizes the software for sites and helps companies integrate their own code into it. PeterZ makes money on tuning Innodb and has at different times provided binaries with performance enhancements for one of the storage engines. Jeremy Cole adds tools to make his consulting work easier. This doesn't even scrape the surface... there are hundreds of projects that exist just to extend MySQL and make it easier to deploy and manage. Companies like Zamanda fill gaps in what the product provides. Open source projects are ecosystems. Any company who "controls" product, only does as long as it continues to be the fastest innovator.


Committers determine where the open source project is headed... They can typically resolve technical problems faster than noncommitters, and have high visibility to the user community.


There is a lucrative business for anyone who can work with the Linux Kernel. Companies who rely on it have found that it is best to have their own in house experts. Sure, they could pay for this, but that means they are beholden to some company. I've heard the "why would someone want to hire someone when they could just buy support from...". For this I refer to the concept of "Jedis build their own lightsabers". You don't find successful companies using Linux who don't have in house experts. I can write an entire article on this point alone. Earlier in MySQL's history we developed our own Support tracking system. I thought it was dumb at the time, simply because there are so many of these on the market. I now think I was wrong, I think it is one of reasons why our support is successful. They have a custom designed tool made for their needs. MySQL support guys are Jedi's and they needed to know how their lightsaber were built.


Developers face new career prospects and paths, since their formal position in an open source project, in addition to their experience and capabilities, determines their value to an employer.


I don't know that I buy this. Developers have the same problems today that they had a decade ago.

  • Are my skills rotting?
  • Will what I am an expert in be gone tomorrow leaving me high and dry for jobs?
  • Do the guys in the front office know what they are doing, or am I wasting my time here?
  • Do I want to keep up with this field, or would finding a profession that requires less of my life be more rewarding?

    Open source has nothing to do with any of these. Projects that are relevant one day, can become irrelevant the next.
  • Link | Leave a comment |

    Comments {7}

    Determining value or signaling value?

    from: dmarti
    date: Apr. 15th, 2007 03:19 pm (UTC)
    Link

    "determines their value" is probably a little strong, but assessing developers' skills is hard. If a developer's actual bugs and code are secret, the job market for developers is a lot like Akerlof's market for lemons.

    Higher salaries for committers might be better explained by less information asymmetry.

    Reply | Thread

    Brian "Krow" Aker

    Re: Determining value or signaling value?

    from: krow
    date: Apr. 15th, 2007 05:49 pm (UTC)
    Link

    I've always preferred to hire open source developers, since I can directly look at their contributions. This has backfired on me once, but otherwise it has worked out fairly well.

    Hiring based on degrees, which is one of the popular options, I have found to be fairly worthless.

    Reply | Parent | Thread

    tjewell

    My potentially irrelevant little comment...

    from: hydrolagus
    date: Apr. 15th, 2007 04:15 pm (UTC)
    Link

    since I am a friend-of-developers rather than a developer myself. From what I have heard in conversations, one of the major drivers in contributing code/bug-fixes to an open source project is to eventually have access to a product that works well: does what it's supposed to do without unnecessary twiddles, obfuscation, or failures.

    Reply | Thread

    Brian "Krow" Aker

    Re: My potentially irrelevant little comment...

    from: krow
    date: Apr. 15th, 2007 05:45 pm (UTC)
    Link

    That is pretty rare. There is a big hurdle to pass to get a bug fix done... the required time to be an active member is quite a bit larger.

    But it does happen, even the "I want to be famous" happens, though I've rarely seen that be successful.

    Reply | Parent | Thread

    Ask Bjørn Hansen

    Re: My potentially irrelevant little comment...

    from: askbjoernhansen
    date: Apr. 22nd, 2007 10:33 am (UTC)
    Link

    With open source projects writing up a bug report with a reasonable test case is often both very easy, useful to the active developers and pays off well.

    Sending an actual patch can be a big hurdle on big projects like mysql, but not so much on a smaller ones (most Perl or Ruby modules for instance).


    - ask

    Reply | Parent | Thread

    Christy

    (no subject)

    from: spristy
    date: Apr. 17th, 2007 09:43 pm (UTC)
    Link

    I could actually see it helping with skill rot. Back when I was contracting, I think I learned one new web application framework per year. Call it one database framework every other year. But I don't consider those "skills". because all such frameworks solve more or less the same problems, so learning a new framework may make HR departments happy but is really not a big deal.

    Conversely, it seems like a lot of the problems you're solving when writing OSS would be new - new problem, new limitations, new thinking. It seems like that would help prevent skill rot. I guess I mean brain rot. Skills are mostly transferrable.

    Reply | Thread

    Brian "Krow" Aker

    (no subject)

    from: krow
    date: Apr. 17th, 2007 11:13 pm (UTC)
    Link

    The frameworks are dead ends from what I can tell... you learn one and you make yourself less hire-able for general work.

    So going to be coming up with some open source project of your own?

    Reply | Parent | Thread