jakarta-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Santiago Gala <sg...@hisitech.com>
Subject Re: Bug handling survey - 80:20 rule
Date Thu, 10 Oct 2002 10:28:09 GMT
Craig R. McClanahan wrote:

>On Fri, 4 Oct 2002, Danny Angus wrote:
>
>  
>
>>Date: Fri, 4 Oct 2002 17:45:48 +0100
>>From: Danny Angus <danny@apache.org>
>>Reply-To: Jakarta General List <general@jakarta.apache.org>
>>To: Jakarta General List <general@jakarta.apache.org>
>>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.
>  
>

This is a very meaningful distinctions. IMO, the fundamental distinction 
here is that of Open vs Closed, not beer-free vs Commercial, where Open 
means Free-freedom (I don't want to go GPL vs BSD here)

>  
>
>>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.
>>
>>    
>>
Commenting on Danny's sentence, you need to make a difference between 
"We" as in each one of us, and "We" as in the community.

Even when each individual developer is interested in "producing an 
intelligent, elegant and efficient solution to a particular problem", 
the community can still produce "a competitor for a commercial product" :-)

There are a lot of colective behaviours going on here, enabled by the 
efficient communication means we are using, which completely make the 
difference. Knowing how to ride this wave is definitely part of the fun.

>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.
>  
>
In my view, this means that succesful OS Product Manager will have lo 
learn to predict fairly accurately the response rate of the community 
for a given situation, and deliver the right expectations 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.
>  
>
In my view, this means that succesful OS Product Managers will have to 
learn to influence (with "brute force" money, persuasion or other means) 
the community to guide efforts in the required direction.

>* 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.
>  
>
In my view, this means that succesful OS Product Managers will have to 
learn to organize support networks for their products in different ways 
as in CS Product Companies.

>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.
>  
>
I have some experience regarding this area, and I think this is an area 
with a lot of future. Most software integration effort will go this way 
in the next years. We have started with things like packaging (linux 
distributions), bundling (tomcat in iPlanet or Apache in Websphere) or 
embedding complete OS products in hardware, but there are a lot of 
promises when you apply this methodology to, for instance, building a 
ERP platform using OS pieces.

>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, for the scheme to work it should be a win-win. At the very least, 
companies leveraging OS packages should aim to improve in the three 
problem areas you pointed (SCHEDULE, CUSTOMER FOCUS, SERVICE/SUPPORT)

>  
>
>>Yes? No?
>>
>>    
>>
>
>Ah, if only life were that simple!  :-)
>  
>

I think that it is not a yes-no question, but a when-how question.

Internet communications and Open Source is changing all the software 
engineering processes, like the press changed th intellectual production 
processes a while ago. Pure in-house or contracted developments are 
disapearing from the market, and integration on top of Open Source is 
leading/will lead the way in the future.

Depending on the nature of the projects, this can go from simple uses of 
OS packages (much like a VB programmer assumes that Visual Basic "is 
required" for her program to run, you can assume that tomcat or struts 
"will be installed there") to minor changes/extensions (writing filters 
for catalina, services for turbine, tag libraries, etc.) to crucial 
enhancements (can you imagine a java VM which would run on top of a 
distributed machine like MOSIX? I would like one of these beasties :-) , 
a good replicating free DataBase would be another of these "killers" )

Once you get used to the fact that you "can" understand the inner 
working of your base tools and modify and debug them (more or less) 
freely, you will never want to use a non-free equivalent again. And I'm 
speaking as a system integrator here.


I catch it very late, but I'm finishing my ApacheCon materials right 
now. Curiously enough, my session is called "Developing Commercial 
Products on top of OS Software", and is a case study covering the 
development of a portal tool using Jetspeed as the base software package.

Regards,
      Santiago

>  
>
>>d.
>>
>>    
>>
>
>Craig McClanahan
>
>
>  
>



--
To unsubscribe, e-mail:   <mailto:general-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:general-help@jakarta.apache.org>


Mime
View raw message