[OSGeo-Discuss] RE: OS and proprietary

[Miles Fidelman]

P Kishor wrote:
> To paraphrase the popular saying, "There are 10 kinds of people in
> this world -- those who see open source lacking what they need and
> choose a proprietary software instead and those who see open source
> lacking what they need and choose to make it better."
>
> If you have the money that you would spend on proprietary software
> anyway, consider hiring an open source developer to develop what you
> want, and then put that functionality back into the open source
> community.
>
>   
Nice in theory, not always workable in practice.  (Note: I write as a 
long-time user and supporter of lots of FOSS.  But then again, I have 
bought lots of proprietary software as well, and worked for companies 
that developed it.)

Historically, most successful open source projects (e.g., GRASS), have, 
at their root, something that had a lot of development money thrown at 
early on - either by a user organization (again, GRASS is a good 
example), or an R&D funder (e.g., the NCSA web daemon, that begat Apache).

Somewhere along the line, the original funder either lost interest (the 
NCSA daemon was no longer a research project), or didn't want to keep 
carrying the development cost by themselves (Zope comes to mind).  At 
that point, making the code freely available, building a user community 
around it, and relying on the community to support the code and make 
incremental improvements makes lots of economic sense.

The key is having that critical mass of serious, funded, development to 
build on.  And then having a user community that is both willing and 
able to throw considerable amounts of skill, time, and effort into 
taking on long-term maintenance and improvement, and well-enough 
organized to manage the entire effort.

Which leads back to the comment that "hiring an open source developer to 
develop what you want, and then put that functionality back into the 
open source community" is sometimes easier said than done.  It depends 
on such things as:

- Are you (or someone in your organization) capable of either developing 
an extension, or selecting and managing a developer?

- Is the software modular enough to allow adding functionality through 
an effort of manageable scope?

- Can you afford the money and time delay involved?

- Who's going to maintain the extension?  Do you care, or are you just 
looking for a one-time solution?  Are you willing to support ongoing 
maintenance?  Is there a broader user community likely to adopt the 
extension?  (Drupal comes to mind as an open source project where 
extensions tend to lag way behind new releases of the core software.  A 
lot of Debian packages also tend to lag several releases behind the 
software on which the packages are based.)

- How well organized is the community around the piece of open source 
software?  (How many Linux distribution have died out due to religious 
wars among their core teams?  On the other hand, the Apache Software 
Foundation provides a very stable base for some critical software, with 
big players such as IBM lining up to throw money and people at 
development, out of pure self-interest.)

If you're in the software business, and depend on a key piece of open 
source software, it makes a lot of economic sense to support it (again, 
IBM and Apache come to mind, as to Red Hat and Linux); but for a user 
organization that needs to solve a problem right spanking now, throwing 
people and money at an open source development may not make a lot of sense.

Sometimes, the easiest solution is to buy a product off the shelf - 
assuming it does the job you need, and is backed by a reliable firm that 
provides reliable support - particularly if it also provides hooks for 
extending it.  Then again, an awful lot of proprietary software is 
expensive, buggy, and if it's missing that one key feature you need, 
you're s*&t out of luck.

Sometimes, the easiest solution is to start with an open source package, 
and extend it.  But sometimes open source software is built of spaghetti 
code, with limited documentation, and a hard-to-work-with community; and 
a lot of open source packages die young.

Each case is different.

-- 
Miles R. Fidelman, Director of Government Programs
Traverse Technologies 
145 Tremont Street, 3rd Floor
Boston, MA  02111
mfidelman at traversetechnologies.com
617-395-8254
www.traversetechnologies.com