Some more arguments for the use of open source software, from the perspective of a government worker
Posted by 10/07/2005
Why open source?
There are a lot of arguments for the use of Open source software by government institutions. Being a government employee and a taxpayer, I have a vested interest in the subject, and have long been an advocate for open source software. This Article expresses a lot of good thoughts on the issue. I have a few more thoughts based on my own experience as a worker.
One problem I see over and over again is then when a product has to be upgraded - there's no money for it. The funds have run out. Years go by. And in the meantime you start writing more and more workaround code to get through the bugs that the old software has, that the upgrade fixes. It seems like your saving money by forestalling an upgrade, but you could also be digging yourself into a bottomless pit of obsolescent code.
I believe a big part of maintaining an application is upgrading it. And that this is often seen as a momentous task, but it should be part of the maintenance. Upgrading should not involve a change request, it should not involve a project plan, it should be in the realm of maintenance.
With open source software it's easy to upgrade. You just read the change log - which is going to be a digestable 1-2 page document, and you incorporate changes. Moving from Ant 1.6.1 to 1.6.2 is no big deal. On the other hand moving from Oracle 9i to 10g is a huge deal. Your typical heavyweight commercial program presents a few problems when it comes to upgrades:
- you can't upgrade until an official release comes out
- it costs so much money to upgrade you have to wait a while
- often you wait so long that the company no longer supports the version, and then there is a big scramble to update - and consolidate years worth of maintenance into months
Avoiding Proprietary Systems
One thing you often see in government IT projects is that the larger and more important the project - and consequently the more essential to the daily business operations it is - the more likely it is to be built by a contractor. This is the opposite of how it should be and I'm not sure why it happens. I would think small, ancillary projects are the best project for outsourcing. What happens is you end up with a huge proprietary systems built by contractors - who hold the keys to your organization - and all the incentives, purely based on human nature, are:
- Make it complicated and difficult to maintain
- Make it painful to switch to any other system
- Create a very customized system that does not work with any other
The advent of Java has seen an emphasis on standards and interoperability, so the situation has improved. And Java has brought corporate sponsorship into the open source world - which could be a blessing or a curse, it's difficult to tell. But there are a lot of outsourced projects running on products like Ant, Hibernate and Struts now - which would have been unusual 5 years ago. But there are still roadblocks.
The Myth of Support and Financial Viability
Often a filter for deciding what software to use is to base it on the financial viability of a company. If they are making over a million dollars a year then you can presume:
- they will stay in business
- they will offer support
Since a lot of open source software does not pass the financial viability test, it fails this test. Often these assumptions do not pan out though. A company can go out of business, or more likely, stop supporting a program, just as easily as a sourceforge project. And the larger the company, the worse the support. Call it the [LawOfEntropy]. You will often get better support, quicker answers, and more responsive help from an open source project then from a commercial vendor. And more importantly, you can diagnose and fix the problem yourself.
Large pool of Testers
A commercial project will have functional tests, they may assemble a team whose job is to design tests and run tests - but with a freely distributed, open source project, you've opened things up to a world which is larger than any team you could possibly assemble.
I see a great potential collaboration of government institutions and learning institutions involving open source software. Both are public institutions whose goals are more social than financial. And both, being publicly funded, need to spend money as efficiently as possible. And ultimately the business of the government needs to be transparent. That was the point of various open records laws that passed over the last few decades. A private company has no such legal requirement.
A Programmer offers a Service, not a Product
Ultimately there may need to be a shift from focusing on the product of a programmer, to focusing on the service. The programmer is someone who pulls together modules, binds components together, researches, contributes to the field. The product that is created, the application, is just a side-effect of that assemblage - and is largely written by a community, rather than an individual.
So Why Do People Write It?
I've often heard people ask why people write open source software. If they are not selling it, why are they making it? I can think of a few reasons:
- Fame - some people get famous - at least in a certain sect of society. Slava Pestov, James Clark, Guido van Rossum, Stefano Mazzocchi, Bram Moolenaar, Bruce Eckel - these are all famous people in my world. It probably pays off financially to be famous (in speaking gigs, book sales, job opportunities) and also just whatever other reasons it is people want to be famous.
- Resume builder - it looks good on the resume
- Contributing to a community - since you are a programmer, your helping other people like you
- Karma - you've used open source stuff, so you contribute back
There are other reasons, but those come to mind quickly.