On Fri, 4 Oct 2002, Danny Angus wrote:
> Date: Fri, 4 Oct 2002 17:45:48 +0100
> From: Danny Angus <[EMAIL PROTECTED]>
> Reply-To: Jakarta General List <[EMAIL PROTECTED]>
> To: Jakarta General List <[EMAIL PROTECTED]>
> Subject: RE: Bug handling survey - 80:20 rule
>
>
> > So, how come the
> > commercial software can still compete with open source products.
>
You're assuming, of course, that you can't have commercial software that
*is* open source :-). Such models do exist -- so I'm assuming you are
primarily talking about closed source commercial software.
>
> IMHO its because on the whole OpenSource contributors are not doing it
> to compete with commercial software, in fact many of us do this to
> provide an alternative to the daily pressures, restrictive working
> practices and profit driven project management of commercial IT.
Having been (and still am) sitting on both sides of this fence, there is
quite a bit of truth to this observation.
>
> We're either much less interested in producing a competitor for a
> commercial product than producing an intelligent, elegant and efficient
> solution to a particular problem, or we're here to collaborate on a
> product to use in our own commercial interests, not in competing in the
> market place.
>
I don't think you can generalize to *all* open source projects not being
interested in competing with commercial packages, but this attitude is
certainly common.
IMHO, there are at least three major factors that means commercial
software isn't going to go away any time soon, no matter what happens in
the open source community:
* SCHEDULE - we all know the standard (and usually pretty sarcastic)
response that we open source developers give to the "when's the next
version going to be released". But this is a very very important
issue for people who are planning projects that depend on that next
release being completed. Yes, commercial software vendors sometimes
miss their dates too, but at least they generally try to meet a
predicatable schedule that can be communicated to customers.
* CUSTOMER FOCUS - like any product, commercial software must meet the
needs of customers in order to be viable. While there are certainly
open source projects that try to do this, I'd bet that commercial
software vendors are perceived as being more responsive in this regard
generally -- it's their whole livelihood at stake, versus an open
source project that is being done for fun or to collaborate on something
interesting.
* SERVICE/SUPPORT - While it is a myth that you can't get support for
widely popular open source projects (check out the Resources pages
for something as small as Struts, for example), it is *definitely*
true for less popular projects, or projects where the developer
community is fairly limited.
Individual open source projects can clearly choose to deal with the
objective realities in each of these three areas, and the ones that do
have no problem competing with commercial closed source software. But the
general perceptions in these areas about the open source community, as a
whole, are fairly accurate IMHO.
On the other hand, the real world is also getting more complex in this
regard, with companies choosing to build commercial products that are
partially or (almost) completely constructed with open source software --
licenses like the Apache Software Foundation license make this trivially
simple.
If a company chooses to leverage an open source product (such as, for
example, what IBM does with the Apache httpd server by building Websphere
around it), do you count that as an open source success, or as a failure?
How about all the hardware products that embed Tomcat to provide a web
based configuration interface? Or commercial application development
frameworks and IDEs that support things like Struts?
Don't forget that many companies leveraging open source packages in this
way *also* fund some of their developers to work on contributing changes
and improvements back to the open source community, too ...
> Yes? No?
>
Ah, if only life were that simple! :-)
> d.
>
Craig McClanahan
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
