Re: Jakarta [was: Effects on corporate backing withdrawals [was: Incubator Proposal: Pig]]

2007-09-29 Thread Roland Weber
Hello Niclas,

 Staying at Jakarta will buy some time, but won't last forever.
 
  If you have ideas on what to do with these small but active
  projects, please come over to [EMAIL PROTECTED] and share your
  thoughts.
 
 Can't Jakarta just be revitalized as a home for small, but mature and stable 
 projects??

I feel Jakarta has to downsize some more before we can think
about reviving it in a new role. A home for small, mature and
stable projects is surely an option, though I don't believe
it will be easy.
The two projects I care about, however, do not match that profile.
They are highly active, evolving, and growing. You can see that
from Jakarta's September board report[1]: 5 releases, all of them
from JMeter and HttpComponents. JMeter released 2.3 final today,
and HttpComponents has three more releases in the pipeline until
the end of the year. Both projects have hundreds of mails on
their lists each month. That's not what I would associate with
mature and stable, which sounds more like maintenance mode.

So, both projects are actively developed and used. We know how
to vote and cut releases. The projects have prospects of growing
and attracting a larger user base, from which we can hope to
get new committers over time. But at the moment, both depend
on a very small group of developers that provide continuity,
with occasional patches from others coming in. And we don't get
the time to grow organically, with Jakarta disintegrating.

I don't know what Sebastian plans for JMeter. Oleg and I will
push for an HttpComponents TLP later this year. Not because we
feel that the project is ready for that move, but because we
see it is the best option left to us. Either we stay at Jakarta
until we're being asked to leave (or shut down), or we make a
move of our own while we can still choose the time to our
convenience. A fallback option is to move from Jakarta to
WebServices, exchanging one umbrella for another. That wouldn't
move us forward, and the impression we got from Jakarta is that
umbrellas are not in favour at the board.
As a TLP, we will have a fighting chance to grow the project
to the point where it no longer depends on just the two of us.
Until that is achieved, we'll be one of those projects that
Niall referred to, with community issues because they didn't
pass through the Incubator. That's why I thought it was a good
occasion to ask for suggestions. The new HttpComponents as well
as the old HttpClient we maintain are being used by Apache
projects, so coming into the Incubator is not an option for
HttpComponents.

I'm sorry if this is getting off-topic. I'm just trying to
tap into the Incubator's experience in community building.

cheers,
  Roland

[1] http://wiki.apache.org/jakarta/JakartaBoardReport-current


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Field of use constraint on OSOA license?

2007-09-29 Thread Jeremy Boynes
The recent Tuscany distribution contains XSDs licensed under the OSOA  
license[1] which contains the following:
Permission to copy, make derivative works of, and distribute the  
Service Component Architecture
JavaDoc, Interface Definition Files and XSD files in any medium  
without fee or royalty as part
of a compliant implementation of the Service Component Architecture  
Specification is hereby granted.


Is the restriction to a compliant implementation a field of use  
constraint that Tuscany project should be concerned about?

--
Jeremy

[1] http://www.osoa.org/xmlns/sca/1.0/license.txt

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Field of use constraint on OSOA license?

2007-09-29 Thread Roland Weber
Hello Jeremy,

Jeremy Boynes wrote:
 The recent Tuscany distribution contains XSDs licensed under the OSOA
 license[1] which contains the following:
 Permission to copy, make derivative works of, and distribute the
 Service Component Architecture
 JavaDoc, Interface Definition Files and XSD files in any medium without
 fee or royalty as part
 of a compliant implementation of the Service Component Architecture
 Specification is hereby granted.
 
 Is the restriction to a compliant implementation a field of use
 constraint that Tuscany project should be concerned about?

No, AFAICT. Every JSR has the same restriction for compliant
implementations. A Field of Use restriction would be not in
embedded devices. I'm not sure how this is handled until
you've reached the point where the implementation passes the
testcases to become a compliant implementation. But I've
never heard of problems with that stipulation either.

cheers,
  Roland

 [1] http://www.osoa.org/xmlns/sca/1.0/license.txt
 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]