I prefer to call it "the monkey house" http://blogs.cocoondev.org/stevenn/archives/000769.html
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 ;-)
;-)
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...
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.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:
* 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.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.. .
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.
Thus, I find that people doing system integration and consultancy, both in big and small companies will naturally prefer Apache-like licenses:And thats why most Apache projects are "tools".. . Not saying this is a bad thing. Just that it TOO has its tradeoffs.
* 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.
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: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 ;-)
* 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
* I find Apache licenses to make us "freer" than free software, removing significant business opportunities from our portfolioagreed.
* 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.
I'm even worse about this :-). English can hardly be called a "natural" language ;-)
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.
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
