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
[EMAIL PROTECTED]
617-395-8254
www.traversetechnologies.com
_______________________________________________
Discuss mailing list
Discuss@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/discuss
