Where does open source software come from?
How do programmers get paid for writing software?
There are some answers to some of these questions in Eric S. Raymond's
paper called "The Magic Cauldron". What follows here turns on some of
ESR's ideas and adds some of my own spin, being someone who has been
paid to write open source software on and off for the last six years.
Software which is written with taxpayer money - either under contract
to a government or by government employees should belong to the
taxpayers. Except where there is a clear and present need for secrecy
for this software it should be released to the public as Free Software
in the RMS sense of the word. Where governments are required to
release into the "public domain", free software developers should
move rapidly to start a GPL'd branch of development and get a leg up
on the profiteers.
Software which is written by faculty and students of
government-subsidized educational institutions should be released to
the public as Free Software under the rationalle of the above paragraph.
Students, both in the institutional sense and in the sense of those
that are undertaking new learning for personal growth and career
enhancement should be encouraged to participate in the development of
Free Software. This allows then to advance a "portfolio" of publicly
viewable works and eliminates the issues that arise during the hiring
process when prospective employers need to see proof of a programmer's
capabilities. Additional motivating factors for being a participant
in open source software under these auspices are discussed at length
in ESR's paper "Homesteading the Noosphere".
Much of the free software that we use today were started and are
developed under the models described so far.
Now let's talk about open source software in business. Say you're a
hardware company. Are you going to make money off of your device
drivers as shrink-wrap software? Why not have the open source
developer community (as contractors) work with your engineers to build
the drivers for you? Yes, some device drivers might be better closed
to protect dwimmer-crafty hardware design, but for the second-string
component designers building mundane boards, what is there to loose?
We'll see more and more where hardware companies adopt open-source
software techniques to drive down end-unit cost.
The shrink-wrap or packaged software business has a small handful of
very wealthy companies which have gotten there because of their
ability to sell software licenses and upgrades. This would lead most
people to believe that most programmers are in fact working for these
few companies making software which would actually be useful outside
the organizations for which they work. And this belief would be
wrong. Most programmers are paid to build glue. Glue that binds old
bits of legacy code together. Glue that binds legacy applications to
commercial applications. Glue that binds commercial apps and legacy
code to stuff that had to get written just because the stuff we could
buy didn't do what we needed done exactly the way we needed it done.
Glue that lets our operating systems talk to our devices. Glue that
lets your customers applications talk to your hardware ;-). And if
you're not writing glue you're writing the invisible embedded stuff
that runs your car, your microwave oven, your PDA and your kid's
Furbies.
All told, commercial application software is a drop in the bucket.
Yes - even the "giants" like Microsoft, Oracle and CA amount to
probably a single-digit percentage of all of the software that's out
there.
So what's that got to do with open source?
Here's my favorite application of open source: you use hired guns to
bail you out of a tight spot. You have them for six months. So they
come in and spend N weeks figuring out how you've glued togther your
special glue and 26 - N weeks hacking on your glue and then they're
gone. So if your shop is running on open source software you get N
free weeks of developer time *up front* because you've probably been
able to find somebody who's already up to speed on the core elements
you're using. Then if you give back any of the work they've done you
get "free" development time from the community - maybe even the same
developer you hired - to maintain the work.
The next step back: you're not generally a "technology" company - you
hire a consulting firm to come in and set up something for you, say
Enterprise Resource Planning or Customer Relationship Management or
Point of Sale or Sales Force Automation. In a closed-source universe
there are generally two alternatives - you pay the company extremely
super big bucks to develop something custom that you own and they
support (for as long as they remain in business) or you pay the
company big bucks to outfit you with whatever it is they're good at
installing and you pay them or someone else for ongoing support. The
third - the Application Service Provider route is currently untested
and is probably going to be a booming business for Linux. If you're
going to pay a consulting company to do one of these gigs, why not
insist that they start with open source components and end by open
sourcing whatever work you pay for? This has a bunch of interesting
effects:
you get all of the CatB benefits of open source
you're regarded as a participant
you're protected against the collapse of any of your suppliers
you can shop for support at any of the open source support
companies like VA, IBM, LinuxCare or RedHat.
Let's take another place where people are being paid to write open
source software. It's become fairly will known in the industry that
any application of significance written on a Microsoft platform is
either subject to seizure by Microsoft or overwhelming marketing
assault by a competitor seized by Microsoft. How does one then
compete under the closed-source shrink-wrap business model in this
space? Find a niche so screwy that MS can't possibly be interested?
Why bother? Better to find a niche in the open source world and brand
the hell out of your approach. Build out your team as a professional
services organization - not a shrink-wrap sweat shop. It is widely
recognized that free implementations of good technology spread like
wildfire and choke off the oxygen from all but the most heavily
marketed or expesnive-to-develop competition.
I see closed-source companies operating in a very precarious situation
over the next 10 years - a narrow operational band bounded above by
software that's stratospherically difficult to implement correctly and
bounded below by hungry armies of open source service contract
companies that rapidly implement and give away anything reasonably
mundane.
So to answer Jim's original questions - both Sendmail and Apache were
originally done by government funded educational and research
institutions. As were lots and lots of other parts of the infrastructure.
As we go forward it's all about how well you know the code and how
well you can adapt it to the meet the needs of the customer.
ccb
[not speaking for VA, Larry does that]
--
Charles C. Bennett, Jr. VA Linux Systems
Systems Engineer, 25 Burlington Mall Rd., Suite 300
US Northeast Region Burlington, MA 01803-4145
+1 617 543-6513 +1 888-LINUX-4U
[EMAIL PROTECTED] www.valinux.com
vi/(emacs) NT/(Linux) qmail/(sendmail) (perl)/python (pepsi)/coke
**********************************************************
To unsubscribe from this list, send mail to
[EMAIL PROTECTED] with the following text in the
*body* (*not* the subject line) of the letter:
unsubscribe gnhlug
**********************************************************
