Women in Technology

Hear us Roar

  What Corporate Projects Should Learn from Open Source
Subject:   Forgets key factors
Date:   2006-03-01 16:47:47
From:   kolding@alum.berkeley.edu
This article forgets two key factors that drive corporate software: budget, and schedule.
Open Source projects usually don't have either.

Pretty much all software projects end up being over both budget and schedule. It's just truism, like the sun will rise tomorrow. But in a corporate world, sometimes those can't slip. My company won't get paid if we miss our release date. A friend at an online retailer once stated "Christmas doesn't slip". When a release date is looming, and things aren't ready, changes happen. Bad decisions get made, or (more often) good decisions which have ramifications later, get made.

How many Open Source projects have hit schedules? Or even announced schedules? How long has it been between release of GnuCash? Or the Gimp? They are typically done when they're done. There's no hard deadlines which must be met.

Similarly, since most open source projects are run by volunteers, there's no budget. No "what do I cut" when the money's running out. The volunteers will just keep on going (or, sometimes, they don't, they just disappear, slipping any future releases).

Full Threads Oldest First

Showing messages 1 through 1 of 1.

  • Forgets key factors
    2006-03-20 13:08:39  dlc311 [View]

    I think that's the mentality that the article addresses. In a consulting company, this doesn't make any sense, because a consultant's job isn't to produce software the is most cost effective. A consultant or a contractor is motivated to do as little as possible for as much as possible. This is why some foresee a "backshoring" or "inshoring" trend in the next 10 years. Software development can only be made cost effective if that development group is supporting the business using it, not a client. The FBI has been the most recent and obvious victim of such disbelief. Given that your goals are for the most cost-effective solutions, deadline predictions are much more accurate, and costs are much lower, while quality increases. Accuracy, reliability, quality, and cost-effectiveness can easily compensate for fixed deadlines, perhaps not with the same clients. As for budget, I haven't read a study in software, nor participated in a project, that doesn't support early-process mistake-aversion because it is cheaper and quicker than streamlined, top-driven pet projects.