www-community mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrew C. Oliver" <acoli...@apache.org>
Subject RANT: Licensing, Business models and success metrics (was Re: answer
Date Thu, 06 Mar 2003 14:53:44 GMT
>
>
>Andrew C. Oliver wrote:
>> This is going to be another one of my long answers to a short question...
>> 
>
>Good! (I crosspost to community. I think it really belongs there ;-)
>  
>
I prefer to call it "the monkey house" 
http://blogs.cocoondev.org/stevenn/archives/000769.html
;-)

>Specifically in server side applications. For instance, as Andy hints in 
>my next quote, a single download from a intranet server in a big 
>corporation can lead to tens of thousands of (unsuspecting) users.
>  
>
Note that its irellevant to me that they actually DO it, just for POI 
its relevant that they considered it.  It would serve little benefit to 
me if they did.  (No money changing hands, unlikely that they'd 
contribute anything back). .  I for one do not seek to have tens of 
thousands of "level 1" users.  (Meaning they barely know how to work 
their IDE).  Whether any will convert to paid consulting gigs has yet to 
be seen, however its not happen yet.  (All gigs have come from 
experienced developers who recognized that "gee, if I talk to my boss 
these guys can certainly get it done faster and cheaper since they 
already know the code and the subject matter").  Not that I haven't 
TRIED to be helpful: http://jakarta.apache.org/site/idedevelopers.html.  
Its just that while I enjoy conducting Java training, I do not enjoy 
doing it via email and I prefer to get paid for it.  So this is why TOO 
many users can be bad.  (unless they are all level 2 or better -- 
meaning they know what the classpath is or where to stick jars in tomcat)

>I don't agree that it is a good metrics, since it's a crisis situation 
>and a lot of other factors could be involved into pricing (product life 
>cycle, etc.). Also, we are not trying to make anybody unhappy, that 
>would be (at most) a side effect of our approach being successful. But 
>the post goes on:
>  
>
This is my personal metric...  I put that under personal because I want 
to put that unit out of business with POI and later the whole company 
out of business with another project I'm working on.  Everyone needs a 
hobby right?  This is mine.

I have facts which back up my belief that we affected this, but I won't 
go into them as its not relevant.  This is my "non-monetary 
compensation".. .  I can't wait to see them on www.f*ckedcompany.com.  
Sadistic?  Maybe.  However, I enjoy it. 

>This is the point I think merits further exposure/discussion. I'm not 
>going to flame Andy on this, since I fully agree with it. If we cannot 
>extract actual benefits from our involvement in Apache projects, the 
>projects will not work/scale well.
>  
>
Not to mention there seem to be more heated discussions...

>Each and everyone involved in Apache projects should benefit in terms of:
>* better career opportunities
>* being better known in the industry
>* having better tools in our daily work toolset
>* higher productivity in integration
>* knowing where technology is moving
>* __fill more here__
>
>The Apache licensing model is oriented towards consultancy/system 
>integration rather than product sales. This is in opposition to other 
>licensing schemes like GNU:
>  
>
I disagree.  The Apache licensing model is oriented towards "club works" 
or towards use by big companies.  I would license a tool if I'm trying 
to see a standard API under such a license.  (I've come to change my 
opinion on this).   I'd probably not license say an AppServer under this 
license.  Why?  I'd want to compete with IBM and BEA and friends, not 
have them share or use my code.  Thats what GPL is good for.

>* If you hold the copyright of a GNU licensed stuff, you can re-license 
>it as closed source (a lot of GNU-licensed projects are doing this, see 
>Aladdin or Transvirtual with ghostscript and kaffe)
>
And I agree that licensing dollars are like crackrock.  You should 
endevour not to become addicted to them.  I think services are the 
revenue stream of the future..  however one should endeavour not to be 
too dogmatic about this.  If you happen to GPL and someone wants to pay 
for a license so that they can embed it, then taking their money sounds 
like something good to do.

There are limitations (how to handle contributor requests for the same) 
but life is a tradeoff.  (you give up the restfulness of death ;-) )

>* If you hold the copyright of an Apache, BSD or Artistic licensed 
>stuff, it is far more difficult to do this, because everybody is free to 
>do the same.
>
>This introduces an asymmetry I don't like WRT GNU licensed projects: the 
>person transferring copyright looses rights WRT the person holding it. I 
>don't critizise this approach with the FSF proper, but I don't like, for 
>instance, kaffe benefiting from my patch and I being unable to benefit 
>in the same way.
>  
>
yes.  This is why such projects need a compensation program that 
guarantees the rights of contributers.  Surely by one patch you 
shouldn't be able to embed the whole thing and sell it in Netscape 
Application Server^M^M^M^M^M^M^^M^M^^M^M^M^M^M^M^^M^M^M 
iPlanet^M^M^M^M^M^M^MSunONE -- However, if 25% of the sourcebase is 
yours or your some similarly "vested" contributor it seems to me you 
should get something, if not just the right to embed it without the 
virus clause applying.. .

>Thus, I find that people doing system integration and consultancy, both 
>in big and small companies will naturally prefer Apache-like licenses:
>* you don't need to care about your customer wanting closed 
>modifications, as they can do them --> less overhead
>* you don't need to care if your customer wants to redistribute the 
>output --> less overhead
>* if you happen to find a niche where closed source or just integration 
>with closed source makes sense, you can do it
>
>This, IMO, is one of the big "assets" and branding elements of the ASF 
>(together with quality). YMMV applies here.
>  
>
And thats why most Apache projects are "tools".. . Not saying this is a 
bad thing.  Just that it TOO has its tradeoffs.

>Some people will find that this would enable commercial companies to 
>"cheat", by keeping their patches private. It doesn't work in the long term:
>* Open "variant" evolves faster, so maintenance of patches is a 
>nightmare (Brian has an interesting essay on this (look for software as 
>a liability), I know this from my fingers :-) ).
>* Private extensions/functionality requires inmense ammounts of money to 
>get people to know about it and use new APIs, while exposing a public 
>API and a RI in Apache can give this with far less investment
>* Open knowledge flows ordins of magnitude faster than closed knowledge
>
>Conclusions? not many:
>* Community success is community (user and developer) benefit, not 
>downloads or size. This is what stroke me of Andy's post
>
Yes I came up with the idea all by myself....actually I stole it from 
one of the web pages Jon wrote a long time ago ;-)

>* I find Apache licenses to make us "freer" than free software, removing 
>significant business opportunities from our portfolio
>
agreed.

>* I like being a small part of such a big movement.
>  
>
There are downsides to the Apache model.  (As there are to the GPL model). 

* Companies start thinking Apache is a great clearinghouse of developers 
to implement their latest proprietary standards.  (JSRs)  This is to the 
detriment of community as some developers are "in the know" and others 
just do what they say.  Projects based on living JSRs cannot truly be 
community-based as some members of the community make decisions that 
others cannot play a part of, not by merit but by legal agreement.
* Companies fork Apache projects and start JSRs based on them and then 
attempt to get Apache to adopt the JSR instead of the free-er codebase.  
This effectively takes control away from the community.
* Attrition - Because developers often cannot support themselves off of 
this model (in competition with big companies with brands), You often 
see attrition at a higher rate than successful GNU projects.
* User-side license dogma - GPL has this too, but to a lesser degree in 
part because there is more GPL/LGP software.  But, assuming its 
opensource, the license is the dummest reason to have to re-implement 
something.

>
>P.S.) You know I'm in flux when I nest parenthesis in my writings 
>(inheritance of my LISP past, I noticed re-reading this rant) ;-) BTW, I 
>don't know if it is legal to do this in natural languages.
>  
>
I'm even worse about this :-).  English can hardly be called a "natural" 
language ;-)

>P.P.S) It's not polished, but I *needed* to express this. It's just what 
>I think, and I *don't* want a licensing flame war.
>
Oh you can't say the word license without starting a flame war.  
However, we'll just ignore them because I always enjoy talking with you 
my friend, even if my young age makes me stronger in my opinions than 
you think appropriate time will tell if this changes with time ;-) :-p

-Andy


---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org


Mime
View raw message