You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@jakarta.apache.org by "Andrew C. Oliver" <ac...@apache.org> on 2003/03/06 15:53:44 UTC
RANT: Licensing, Business models and success metrics (was Re: answer
>
>
>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: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: RANT: Licensing, Business models and success metrics
Posted by Santiago Gala <sg...@hisitech.com>.
Andrew C. Oliver wrote:
(...)
> I prefer to call it "the monkey house"
> http://blogs.cocoondev.org/stevenn/archives/000769.html
> ;-)
>
Now that I got you back into "the monkey house", even if briefly, we can
remove the CC: jakarta
BTW: how in the hell has Stevenn found that I'm here just waiting for a
pretty girl to "knock on me"? :-)
(...)
> 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.
>
Let me play "elder brother". This is closer to the "Dark Side of the
Force" than I like. But, as Conrad would have said: "A man must work to
some end", though the context is fairly different.
http://www.online-literature.com/conrad/nostromo/6/
I don't say that I don't take my trips to the dark side. ;-)
(...)
> 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
That's the producers. I was talking about the consumers (of Apache
Licensed stuff). You see, there are always two sides in a rope. (I've
just invented a new English saying)
But it is true: big companies will license them, consultants and
integrators (working for/in) big, medium/small companies or independent,
will use them. Contributors will come from both ends.
(...)
> 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.
>
But you would need a good niche. see below tools/apps.
> There are limitations (how to handle contributor requests for the same)
> but life is a tradeoff. (you give up the restfulness of death ;-) )
vs the soapiness of what? ;-)
http://www.google.com/search?q=rest+vs+soap
(...)
> And thats why most Apache projects are "tools".. . Not saying this is a
> bad thing. Just that it TOO has its tradeoffs.
>
In a networked environment you have no longer tools vs applications, but
tools vs services ;-)
>> 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 respect him much more now than the first time I saw him falling on
uncautious newbies (I think it was on me, actually):
http://www.geocrawler.com/mail/thread.php3?subject=i18n+bug+nailed+down%21&list=449
(...)
> 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.
The two bullets would not be bad (some communities are very closed) if
the JSR was more open, more like the W3C standards. Specially if the big
companies had to play their cards in public. I'm strongly in favour of
this. I mean, they would need not just to win, but to convince.
> * 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.
Ricardo Rocha's view on this was like:
I make money as a Consultant. To keep being a good Consultant, I need to
experiment and write code. I give the code for free, just like a
musician would go to the "tube" to rehearse and make some bucks.
Doing this in Apache brings me additional exposure "for free". The
balance was supposed to be good overall.
This was a couple of years ago. I wonder where he is now.
(...)
>> 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
>
I see that your Spanish lessons are going well ;-)
I'm sure your opinions will stand over time. I wrote this while I was a
bit depressed. Now my back is getting better as Spring approaches.
Regards,
Santiago
> -Andy
---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org
Re: RANT: Licensing, Business models and success metrics (was Re:
answer
Posted by "Andrew C. Oliver" <ac...@apache.org>.
>
>
>This is pretty offensive stuff, I don't believe that it is right for you
>
Don't read it.
>If you're bitter enough about this to fight with these people go do it,
>
I'm not bitter about anything...
-Andy
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
RE: RANT: Licensing, Business models and success metrics (was Re: answer
Posted by Danny Angus <da...@apache.org>.
Andy,
This is pretty offensive stuff, I don't believe that it is right for you to express these views here, they can only harm reputations, personal and community, and create tension.
If you're bitter enough about this to fight with these people go do it, but please don't drag us all down to this level by association.
d.
> 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.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org