Re: anyone know the progress of the Maven top level proposal?
WHEREAS, the Board of Directors deems it to be in the best interests of the Foundation and consistent with the Foundation's purpose to establish a Project Management Committee charged with the creation and maintenance of open-source software related to Java software development tools which are predicated on the use of Maven's Project Object Model (POM), for distribution at no charge to the public. i think that is an appropriate narrowing of scope, though it seems a bit self-referential. so let's start from here, shall we? is the above wording satisfactory to the maven people? is it satisfactory to the board? if not in either case, let's try to constructively fix it, and leave personalities out of it. let's work *together*. It is reasonable. My only concern is that defining it as POM centric may be too restrictive. I have always seen maven as a suite of project management / analysis / comprehension tools which aim to be simple to take advantage of yet flexible to extend (in other words, the most bang for your buck). The POM has been a key factor in meeting these goals, but in some ways is an implementation detail. Already two of the seed projects we are interested in (the SCM abstraction and the artifact download mechanism) are intended to be used by maven, but also other projects, and thus independent of the POM. So my question: is there anything preventing the project from reevaluating and refining our charter in the future as the project evolves? Is it even neccesary or do we just assume a project will evolve and that is just the way it is? -- jt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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 --
Re: anyone know the progress of the Maven top level proposal?
James Taylor wrote: So my question: is there anything preventing the project from reevaluating and refining our charter in the future as the project evolves? Is it even neccesary or do we just assume a project will evolve and that is just the way it is? The same process that is used to create a project (i.e., submitting a resolution to the board) can be used to ammend a project. -- jt - Sam Ruby - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RANT: Licensing, Business models and success metrics
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 myselfactually 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%21list=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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
