Re: anyone know the progress of the Maven top level proposal?

2003-03-06 Thread James Taylor
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

2003-03-06 Thread Andrew C. Oliver

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?

2003-03-06 Thread Sam Ruby
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

2003-03-06 Thread Santiago Gala
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]