[PROPOSAL] The future of Jakarta

Hi,

Ok, I've followed the commons TLP vote thread with some interest
because it seems to impact directly on the end-game for Jakarta.

I believe that we have to make some pretty fundamental decisions about
that future before we can fully resolve the commons TLP issues.

0/ Do we agree that the end-game is dissolution of the Jakarta PMC and
closure of the project?
Pro - Draws a line under the reorg effort which has gone on for 3 or
4 *years*.
Con - Removes the remaining tangible & historic links between former
Jakarta sub-projects.

1/ If so do we wish to preserve the Jakarta brand? (the website and
possibly general@)
Pro - As Ted H. says "We should stop thinking of "Jakarta" only as
an entity, and go back to thinking of it as to the ASF synonym for
"Java", as originally intended."
With this thought in mind around 10% of the referrals to
james.apache come from jakarta.apache.
Con - Others consider that the effort of maintaining the resources
would be unacceptable to anyone.

2/ If we believe that the brand should be preserved should the commons
TLP take ownership of the brand (if/when Jakarta PMC is dissolved)
Pro - Commons is an active community which continues to fulfil the
jakarta==java remit.
Con - Commons is not necessarily interested in the brand or
maintenance of its resources. (would people from other projects step
up)

3/ If we believe that a commons TLP should not own the brand are any
of the alternative options acceptable?
- Retain the Jakarta PMC solely to maintain the brand
- Move ownership of the brand to the prc (should they agree to have it)
- Move ownership of the brand to projects.apache maintainers


x/ Should we consult more widely the Members and/or the Board?

My own (2c) opinion is that:

0/ Yes dissolve the jakarta pmc

1/ Yes preserve the brand

2/ If commons PMC would be comfortable with this it would be my
preferred choice, *and* it would resolve the naming issue because the
project could be "Jakarta Commons" which is a minor change from the
sub-project name Jakarta/Commons

3/ If commons PMC would be against this then I think we should approach the prc.

x/ Don't know

In essence are we in favour of a revolutionary end or an evolutionary one?

WDYT?

d.

Re: [PROPOSAL] The future of Jakarta

------=_Part_251580_23671677.1179224174345
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

On 5/15/07, Danny Angus wrote:
>
> Hi,
>
> Ok, I've followed the commons TLP vote thread with some interest
> because it seems to impact directly on the end-game for Jakarta.
>
> I believe that we have to make some pretty fundamental decisions about
> that future before we can fully resolve the commons TLP issues.
>
> 0/ Do we agree that the end-game is dissolution of the Jakarta PMC and
> closure of the project?
> Pro - Draws a line under the reorg effort which has gone on for 3 or
> 4 *years*.
> Con - Removes the remaining tangible & historic links between former
> Jakarta sub-projects.
>
> 1/ If so do we wish to preserve the Jakarta brand? (the website and
> possibly general@)
> Pro - As Ted H. says "We should stop thinking of "Jakarta" only as
> an entity, and go back to thinking of it as to the ASF synonym for
> "Java", as originally intended."
> With this thought in mind around 10% of the referrals to
> james.apache come from jakarta.apache.
> Con - Others consider that the effort of maintaining the resources
> would be unacceptable to anyone.
>
> 2/ If we believe that the brand should be preserved should the commons
> TLP take ownership of the brand (if/when Jakarta PMC is dissolved)
> Pro - Commons is an active community which continues to fulfil the
> jakarta==java remit.
> Con - Commons is not necessarily interested in the brand or
> maintenance of its resources. (would people from other projects step
> up)
>
> 3/ If we believe that a commons TLP should not own the brand are any
> of the alternative options acceptable?
> - Retain the Jakarta PMC solely to maintain the brand
> - Move ownership of the brand to the prc (should they agree to have it)
> - Move ownership of the brand to projects.apache maintainers
>
>
> x/ Should we consult more widely the Members and/or the Board?
>
> My own (2c) opinion is that:
>
> 0/ Yes dissolve the jakarta pmc
>
> 1/ Yes preserve the brand
>
> 2/ If commons PMC would be comfortable with this it would be my
> preferred choice, *and* it would resolve the naming issue because the
> project could be "Jakarta Commons" which is a minor change from the
> sub-project name Jakarta/Commons
>
> 3/ If commons PMC would be against this then I think we should approach
> the prc.
>
> x/ Don't know
>
> In essence are we in favour of a revolutionary end or an evolutionary one?
>
> WDYT?
>
> d.
>
> ------------------------------------------------------------ ---------
> To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: general-help@jakarta.apache.org
>
>
Hello to everybody,

my personal opinion differes slightly.

I still believe that we have to preserve Jakarta as a project summoning the
Java
projects in the foundation. If you ask me directly "Do we need another
Jakartas
like for .NET for instance?" - I would say yes. Those new Jakarta, or
"Nairobi" or
whatever we decide to call it has to be a TLP, and has to have a commons
project,
and has to have a PMC and everything else. Then,part of our current .NET
projects
could be transfered to the .NET-commons one.

Actually I have been following the mail lists for more than three years by
now, although
I am part of the Jakarta project for less than three months, so you
don't need to consider
my thoughts seriosly.

I am curious to hear what Martin van den Bemt has to say, as I know he is
going to
lead a presentation on the ApacheCON USA with the exact same name.


Have a nice day.


--
Regards, Petar!
Karlovo, Bulgaria.

Public PGP Key at:
http://keyserver.linux.it/pks/lookup?op=get&search=0x1A15B53 B761500F9
Key Fingerprint: AA16 8004 AADD 9C76 EF5B 4210 1A15 B53B 7615 00F9

------=_Part_251580_23671677.1179224174345--

Re: [PROPOSAL] The future of Jakarta

On Tue, 2007-05-15 at 10:22 +0100, Danny Angus wrote:

0/ - Dismember the current Jakarta PMC - +1
1/ - Yes, preserve the brand - +1000
2/ - No. The commons PMC will run the commons project. A possible
Jakarta PMC will not have the attention that might be needed. - -1
3/ - -1 on the PRC. They have enough to do running their stuff and they
are not really interested in the day-to-day business of running a PRC.

Here is a thought: Do we need a PMC?

If we rethink Jakarta as "Java @ Apache", it will be our gateway for
Java interested developers into Apache. So what we need is sort of a
portal site. Basically a subset of projects.apache.org, branded for
Java. Those projects that feel they want to be on add a special tag (or
just Java) to their DOAP files and off we go. Automatic web site.

This is nothing fancy.

And we keep some mailing lists: general@jakarta. announce@jakarta. Maybe
a users@jakarta which is intended for people to ask about Java stuff and
get redirected. Needs maybe one or two more web pages.

Build the stuff and a nice front page that gets a news ticker similar to
what Jakarta has today, add the "these are our rules pages" which we
also have today, as these are the base for many other projects, ready.

Do we need a PMC? Or could this be an effort run by an existing PMC? For
me, infra would be the logical solution. Because, the whole portal thing
is mainly that. Infrastructure.

- create jakarta-site@infra
- let anyone interested subscribe
- get a repository which contains the site and hand out permissions for
it
- wait for a community to gather.

This is a largely stable effort. There is not much work in it (IMHO).
Why add the overhead of a PMC?

I'd like to contribute to that effort.

Best regards
Henning



> Hi,
>
> Ok, I've followed the commons TLP vote thread with some interest
> because it seems to impact directly on the end-game for Jakarta.
>
> I believe that we have to make some pretty fundamental decisions about
> that future before we can fully resolve the commons TLP issues.
>
> 0/ Do we agree that the end-game is dissolution of the Jakarta PMC and
> closure of the project?
> Pro - Draws a line under the reorg effort which has gone on for 3 or
> 4 *years*.
> Con - Removes the remaining tangible & historic links between former
> Jakarta sub-projects.
>
> 1/ If so do we wish to preserve the Jakarta brand? (the website and
> possibly general@)
> Pro - As Ted H. says "We should stop thinking of "Jakarta" only as
> an entity, and go back to thinking of it as to the ASF synonym for
> "Java", as originally intended."
> With this thought in mind around 10% of the referrals to
> james.apache come from jakarta.apache.
> Con - Others consider that the effort of maintaining the resources
> would be unacceptable to anyone.
>
> 2/ If we believe that the brand should be preserved should the commons
> TLP take ownership of the brand (if/when Jakarta PMC is dissolved)
> Pro - Commons is an active community which continues to fulfil the
> jakarta==java remit.
> Con - Commons is not necessarily interested in the brand or
> maintenance of its resources. (would people from other projects step
> up)
>
> 3/ If we believe that a commons TLP should not own the brand are any
> of the alternative options acceptable?
> - Retain the Jakarta PMC solely to maintain the brand
> - Move ownership of the brand to the prc (should they agree to have it)
> - Move ownership of the brand to projects.apache maintainers
>
>
> x/ Should we consult more widely the Members and/or the Board?
>
> My own (2c) opinion is that:
>
> 0/ Yes dissolve the jakarta pmc
>
> 1/ Yes preserve the brand
>
> 2/ If commons PMC would be comfortable with this it would be my
> preferred choice, *and* it would resolve the naming issue because the
> project could be "Jakarta Commons" which is a minor change from the
> sub-project name Jakarta/Commons
>
> 3/ If commons PMC would be against this then I think we should approach the prc.
>
> x/ Don't know
>
> In essence are we in favour of a revolutionary end or an evolutionary one?
>
> WDYT?
>
> d.
>
> ------------------------------------------------------------ ---------
> To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: general-help@jakarta.apache.org

Re: [PROPOSAL] The future of Jakarta

On Tue, 2007-05-15 at 21:56 +0200, Henning Schmiedehausen wrote:
> On Tue, 2007-05-15 at 10:22 +0100, Danny Angus wrote:
>
> 0/ - Dismember the current Jakarta PMC - +1
> 1/ - Yes, preserve the brand - +1000
> 2/ - No. The commons PMC will run the commons project. A possible
> Jakarta PMC will not have the attention that might be needed. - -1

^Jakarta PMC^Jakarta site^

> 3/ - -1 on the PRC. They have enough to do running their stuff and they
> are not really interested in the day-to-day business of running a PRC.

^running a PRC^running as the PMC for Jakarta^

gee, why am I off my meds today? :-(

Best regards
Henning

--
Henning P. Schmiedehausen -- hps@intermeta.de | J2EE, Linux, |gls
91054 Buckenhof, Germany -- +49 9131 506540 | Apache person |eau
Open Source Consulting, Development, Design | Velocity - Turbine guy |rwc
|m k
INTERMETA - Gesellschaft fuer Mehrwertdienste mbH - RG Fuerth, HRB 7350 |a s
Sitz der Gesellschaft: Buckenhof. Geschaeftsfuehrer: Henning Schmiedehausen |n

Re: [PROPOSAL] The future of Jakarta

On 5/15/07, Danny Angus wrote:
> Hi,
>
> Ok, I've followed the commons TLP vote thread with some interest
> because it seems to impact directly on the end-game for Jakarta.
>
> I believe that we have to make some pretty fundamental decisions about
> that future before we can fully resolve the commons TLP issues.
>
> 0/ Do we agree that the end-game is dissolution of the Jakarta PMC and
> closure of the project?

+1. Our current system needs to change.

> 1/ If so do we wish to preserve the Jakarta brand? (the website and
> possibly general@)

+1. I like the idea of keeping general.

Effectively we're talking about the much vaunted yet failed to
materialize federation concepts. XML are ahead of us in this position;
they have one project left (Xindice) for which my advice is sending it
TLP and then all they will have left is a moribund PMC and the
federation work they've done. Which I think is much like the
java@apache page I added a couple of years back (and removed not long
ago).

> Con - Others consider that the effort of maintaining the resources
> would be unacceptable to anyone.

We need to make sure it is self-maintaining to a large extent. The
DOAP stuff might be a way to go, though I think we would want to mix
it with branding and original content.

> 2/ If we believe that the brand should be preserved should the commons
> TLP take ownership of the brand (if/when Jakarta PMC is dissolved)
> Pro - Commons is an active community which continues to fulfil the
> jakarta==java remit.
> Con - Commons is not necessarily interested in the brand or
> maintenance of its resources. (would people from other projects step
> up)

There's a huge tie between the portal (federation) idea and the
commons idea. Both exist as a span for the projects in their category.
I'd rather see two groups showing responsibility rather than lumping
it on the one PMC. So -1 on this one.

> 3/ If we believe that a commons TLP should not own the brand are any
> of the alternative options acceptable?
> - Retain the Jakarta PMC solely to maintain the brand

Maybe not so bad. It's a good start to being Java@Apache as far as
committers/members go. We could extend it such that it's very open to
people being added. For example; there'd be no point having a Jakarta
committer without them being on the PMC.

> - Move ownership of the brand to the prc (should they agree to have it)

-1. StackOverflow.

> - Move ownership of the brand to projects.apache maintainers

-1. StackOverflow.

> x/ Should we consult more widely the Members and/or the Board?

I'm very tempted to ask for opinions on the federation idea on behalf
of both Jakarta and XML as they're both hitting the point of needing
to figure out how we would organize it. I think that part is
definitely on the shoulders of the board/members.

If we end up with code that is in maintenance (Slide, ECS, Alexandria,
JServ, whatever); are we suggesting the Jakarta PMC would handle it or
some other random group?

Hen

Re: [PROPOSAL] The future of Jakarta

On 5/15/07, Danny Angus wrote:
> 0/ Do we agree that the end-game is dissolution of the Jakarta PMC and
> closure of the project?
> Pro - Draws a line under the reorg effort which has gone on for 3 or
> 4 *years*.
> Con - Removes the remaining tangible & historic links between former
> Jakarta sub-projects.

At the ASF, we let them that do the work make the decisions. (Mainly
because we have to ... otherwise, there would be no one willing to do
the work!) We can talk about end-games until Sol goes nova, but in
the end the volunteers who do the work will make the decision.

So far, the subproject committers have been deciding to create their
own TLP. Not because the Jakarta PMC said so, but because the
subproject committers said so.

The one proactive step we could take is to set a deadline for other
TLPs to migrate or to find some other home, either as part of another
TLP, or with another project host. Or, we could just wait the
remaining subprojects out, and let nature take its course over the
next year or three.


> 1/ If so do we wish to preserve the Jakarta brand? (the website and
> possibly general@)
> Pro - As Ted H. says "We should stop thinking of "Jakarta" only as
> an entity, and go back to thinking of it as to the ASF synonym for
> "Java", as originally intended."
> With this thought in mind around 10% of the referrals to
> james.apache come from jakarta.apache.
> Con - Others consider that the effort of maintaining the resources
> would be unacceptable to anyone.\

The goodness of the Jakarta brand isn't the result of working on the
Jakarta brand. It's the result of fostering healthy communities that
create great software. Now, those communities have gone on to create
their own TLPs, and to create their own brands. Sure, Jakarta has name
recognition. But so does Ant and Maven and Struts and Tapestry and
Velocity.

Essentially, Jakarta was the first incubator. Now we have a top-level
Incubator, and most of our subprojects have gone on to become TLP too.
I think Java at Apache has succeeded beyond anyone's wildest dreams.
Today, the communities we fostered don't need the crutch of an
uber-project. They can stand alone, and for that we should be happy!

But not to worry. Whenever we foster healthy communities that create
great software, we will create another great brand. It's what we do.
:)


>
> 2/ If we believe that the brand should be preserved should the commons
> TLP take ownership of the brand (if/when Jakarta PMC is dissolved)
> Pro - Commons is an active community which continues to fulfil the
> jakarta==java remit.
> Con - Commons is not necessarily interested in the brand or
> maintenance of its resources. (would people from other projects step
> up)

At the ASF, great brands are created by healthy communities that
create great software. I would say that the Commons certainly fits
that bill. An excellent way to preserve the Jakarta name would be to
lend it to the Jakarta Commons TLP. After all, the Commons had a lot
to do with creating the Jakarta brand as it exists today.


> 3/ If we believe that a commons TLP should not own the brand are any
> of the alternative options acceptable?
> - Retain the Jakarta PMC solely to maintain the brand
> - Move ownership of the brand to the prc (should they agree to have it)
> - Move ownership of the brand to projects.apache maintainers

An Apache Jakarta Commons does not obviate a Jakarta federation or a
Jakarta portal. If anything, reuse of the name increases its value. We
can have our cake and eat it too!


> x/ Should we consult more widely the Members and/or the Board?

At the ASF level, when we talk about protecting a brand, we usually
mean "give credit where credit is due". Being a meritocracy, we don't
want other people diluting our brand by claiming our work as theirs,
or their work as ours. So long as the Jakarta brand is not being
poached by a third-party, I doubt that anyone else would care. From an
ASF perspective, the only things of value are those things that
attract qualified volunteers. From a marketing perspective, a "brand"
may attract downloads, but I don't know if it attracts volunteers.

-Ted.

Re: [PROPOSAL] The future of Jakarta

.....so this thread died again without a conclusion or resulution.

My take with as few words as possible:

* push for active project to go TLP
* jakarta.apache.org - the portal to all java projects at apache.
Just a shell - but let's keep the brand. Not necessarily a PMC
required. (Although a non-code project trying to improve
collaboration between java projects would be an idea to discuss)
* ${commons}.apache.org - as people have concerns about the name (as
there is more than java) let's find a new one.
- commonsj
- jcommons
- ...
* dormant.apache.org - maybe a place where we put not just old stuff
from jakarta

cheers
--
Torsten

Re: [PROPOSAL] The future of Jakarta

"Danny Angus" writes:

> Ok, I've followed the commons TLP vote thread with some interest
> because it seems to impact directly on the end-game for Jakarta....


This thread has been more quiet than I expected. A couple of quick
thoughts:

Henri and Henning seem to have the same ideas about Jakarta becoming a
"portal" or "federation" and I'm +1 for that. I think that's a great
idea and it's low maintenance. Really, what more would you need than
the general@ list?

As for dormant code, leave it where it is. If we still have a few
committers working on it and making releases occasionally, then we'd
still need a functional PMC. Otherwise, if we get enough noise about
a subproject, it can be revived (perhaps with help from the
Incubator).

And the site should be as self-maintaining as possible, picking up
news and releases from all other java projects at apache. I would
think there is no more qualified group of people to put together such
as site than we have in Jakarta/Apache.

--=20
J Aaron Farr jadetower.com [US] +1 724-964-4515=20
馮傑ä»=81 cubiclemuses.com [HK] +852 812=
3-7905

ad "dormant" code: what about "matured" code? (Re: [PROPOSAL] Thefuture of Jakar

J Aaron Farr wrote:

.... cut ...
> As for dormant code, leave it where it is. If we still have a few
> committers working on it and making releases occasionally, then we'd
> still need a functional PMC. Otherwise, if we get enough noise about
> a subproject, it can be revived (perhaps with help from the
> Incubator).
>
.... cut ...

There may be many reasons why a project turned "dormant": no interest
(dead technology), committers having gone astray, etc.

One reason that may be special is a project which got developed, is
used, but there is no reason to develop it further. If classifying a
project as "matured" it still may need fixing of problems and/or
enhancements over time, making it necessary to create a new distribution.

The idea of putting a "matured" project into the "incubator" realm does
not sound "right" to me. It would not be a project which needs to gain
additional developers to "grow", if it has become clear that it is
matured. Or with other words: I would not expect a "matured" project to
get out of an "incubator", which (from the name) is probably meant to
try out, interest, nurture new projects. Also morphing a matured project
into a TLP seems not to be concludent to me (a TLP should be either an
umbrella for other "little" active projects that belong somehow
together, or be a project that gets actively developed for the
foreseeable future and has a broad developer and user community).

Case in question: the Beans Scripting Framework. Version 2.4.0 has gone
Golden last fall and it is expected to be stable. There may be new
engines that get developed for this Java scripting framework, but from
todays perspective, there are no new features for 2.4.0 that can be
foreseen. So 2.4.0 would be in "matured" mode, people are using it and
maybe new Java developers take advantage of it.

There is a new version (3.0) of BSF in beta, created according to the
JSR-223 specs, implementing the official Java scripting framework in
opensource under an Apache license, and can be deployed starting with
Java 4. There are plans by ant to eventually test it againast the TCK.
Now this version is in active development, but if everything goes well,
it will become "mature" once it is officially released. Then this
project would be in "maintenance" mode as well, mainly bug-fixing and
supporting users will be necessary. Of course, if Sun's Java scripting
framework gets enhanced, then these enhancements would probably be
incoroportated into the future BSF 3.0.

Unless there are already rules that mandate that projects that got
developed to a point after which they go into "maintenance" mode need to
go into the "incubator", I would suggest to create a new classification
for such projects. They should be named "matured". Depending whether
there are committers who maintain matured projects, they should be
further qualified as "maintained" projects, or otherwise be put into an
archive of unmaintained matured projects.

---rony

RE: [PROPOSAL] The future of Jakarta

Torsten Curdt wrote on Thursday, May 17, 2007 1:42 AM:

> ....so this thread died again without a conclusion or resulution.

because there seems none. Any attempt in any kind of direction has been =
vetoed down and for me it is pointless to bring the same arguments again =
in a new thread.

[snip]

- Jörg

Re: [PROPOSAL] The future of Jakarta

On 5/21/07, Jörg Schaible wrote:

> Any attempt in any kind of direction has been vetoed down and for me it i=
s pointless to bring the same arguments again in a new thread.

Jorg,
Searching through my mail I don't really see you advancing any
"arguments" about the future of Jakarta.

Perhaps you could consider repeating them for the benefit of those of
us who didn't hear what you said?

It would be sad if people who have an opinion choose not to express it
in a thread explicity about the future of Jakarta on the pmc list
just because it may have already been expressed in Commons dev or poi
dev or wherever else.

On the other hand if there really is the level of apathy which the
inactivity in this thread hints at then the choices are pretty clear.

d.

Re: [PROPOSAL] The future of Jakarta

On 5/21/07, J Aaron Farr wrote:

> This thread has been more quiet than I expected.

I thought so too.

There are two points which I'd like to make from the things that have
been said so far,

1/ From Ted H. "Whenever we foster healthy communities that create
great software, we will create another great brand. It's what we do."

That's a really good point, and one which more than anything else has
raised a doubt in my mind as to the benefit of retaining the Jakarta
brand.

2/ It seems that we have a consensus forming around the idea that it
would be worthwhile retaining some resources in a low-maintenance way.
However its not clear where the ownership of these would lie.

I like the idea that http://jakarta might aggregate news content from
java projects. Differentiating itself from http://projects by being
the source of news about apache java projects.

d.

Re: [PROPOSAL] The future of Jakarta

On 5/21/07, J Aaron Farr wrote:

> This thread has been more quiet than I expected.

Actually, thinking about it, perhaps that's because we all think we
know where this is inevitably going and we're just waiting for it all
to settle out.

d.

Re: [PROPOSAL] The future of Jakarta

My silence is because I think I made my preferred option quite clear way too many times.

Mvgr,
Martin

Danny Angus wrote:
> On 5/21/07, J Aaron Farr wrote:
>
>> This thread has been more quiet than I expected.
>
> Actually, thinking about it, perhaps that's because we all think we
> know where this is inevitably going and we're just waiting for it all
> to settle out.
>
> d.
>
> ------------------------------------------------------------ ---------
> To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: general-help@jakarta.apache.org
>
>
>

RE: [PROPOSAL] The future of Jakarta

Hi Danny,

Danny Angus wrote on Monday, May 21, 2007 10:47 AM:

> On 5/21/07, Jörg Schaible =
wrote:
>=20
>> Any attempt in any kind of direction has been vetoed down
> and for me it is pointless to bring the same arguments again
> in a new thread.
>=20
> Jorg,
> Searching through my mail I don't really see you advancing any
> "arguments" about the future of Jakarta.
>=20
> Perhaps you could consider repeating them for the benefit of those of
> us who didn't hear what you said?

Well, I follow the discussion quite for a while and anything was already =
said or proposed by other people and I could not add something new. So I =
limited myself to vote.

> It would be sad if people who have an opinion choose not to express it
> in a thread explicity about the future of Jakarta on the pmc list
> just because it may have already been expressed in Commons dev or poi
> dev or wherever else.=20

IMHO it does not help, repeating the same arguments.
=20
> On the other hand if there really is the level of apathy which the
> inactivity in this thread hints at then the choices are pretty clear.

So, here you do imply something ;-)

But to recap, we had

1/ Open-up Jakarta to all committers, was vetoed
2/ Merge commons into Jakarta, was vetoed
3/ Move commons into own TLP, was vetoed

So what's left in your opinion?

I don't buy the Jakarta=3DJava-Portal solution, since I believe it fails =
the doing. Option 2 would have been my personal choice, since=20
- we keep the brand
- we state that we're Java centric
- we wrap a greater community about "matured/left-over/maintained only" =
components

Any Jakarta project that feels uneasy because it
- has an isolated community
- has a broader scope than "Java"
should consider a TLP

Option 3 from above was raised, because 2 did not make it and it would =
have forced the Jakarta left behind projects to make a real statement of =
their own. Now we're stuck to the status-quo and I see no way out of it =
anymore (or should we try to start a vote on those issues in =
periodic times of 6 months unless one of it passes?).

Out of ideas,
Jörg

Re: [PROPOSAL] The future of Jakarta

On 5/21/07, Jörg Schaible wrote:

> 1/ Open-up Jakarta to all committers, was vetoed
> 2/ Merge commons into Jakarta, was vetoed
> 3/ Move commons into own TLP, was vetoed
>
> So what's left in your opinion?

Work with the people who cast the deadlocking vetoes to resolve their
issues and uncover a compromise which is acceptable to the majority.

I'm not sure why 1/ is vetoed, unless this is related to the POI
confusion over M$ IP. In which case POI TLP should remove that veto.

2/ commons TLP should resolve this

3/ veto was mainly detail around name and the wording of the
resolution, no reason to suppose this won't be resolved. the proposal
received -1's but the people who voted -1 should work with the
community to get their concerns resolved, not simply block all
progress.

d.

Re: [PROPOSAL] The future of Jakarta

On 5/21/07, Jörg Schaible wrote:
>
> But to recap, we had
>
> 1/ Open-up Jakarta to all committers, was vetoed
> 2/ Merge commons into Jakarta, was vetoed
> 3/ Move commons into own TLP, was vetoed

Each of those proposals could be voted down, but are not subject to
veto. In other words, a -1 expressed in such a vote is just a -1, not
a veto.

> Any Jakarta project that feels uneasy because it
> - has an isolated community
> - has a broader scope than "Java"
> should consider a TLP

+1

- Sam Ruby

Re: [PROPOSAL] The future of Jakarta

On 5/21/07, Danny Angus wrote:
> 2/ It seems that we have a consensus forming around the idea that it
> would be worthwhile retaining some resources in a low-maintenance way.
> However its not clear where the ownership of these would lie.

Like anything else ASF, the "ownership" will lie with the volunteers
who actually do the work.

JAKARTA AS A PORTAL

If someone wants to turn Jakarta into a Java portal, then turn Jakarta
into a Java portal. Some of the codebases may still be under the
Jakarta PMC umbrella, but would have little effect on using the
Jakarta site as a portal to the ASF's Java assets.

To a great extent, it already *is* a portal. The only real difference
would be to carry "news" from any ASF Java product, and to list all
the Java products, not just Jakarta and ex-Jakarta. (We should also
keep in mind that we have at least three multi-language projects with
a Java product: iBATIS, Logging, and Lucene.)

Anyone interested in such a thing can start now. There's no need for a
vote. Changes to ASF websites have always been commit-then-review. So,
commit. :)


INACTIVE CODEBASES

As to inactive projects or Jakarta subprojects, we had that discussion
on the members list. Tthe general consensus was to "let sleeping dogs
lie". If a project is inactive, the most we should do is post a note
to that effect on the website. If someone wants to reactive a project
later, then one or more interested people can apply to the incubator.


REMAINING JAKARTA SUBPROJECTS

The rest of the Jakarta subprojects can either hang around for a few
more years, or we could force the TLP issue with a deadline, and then
tag the stragglers as "inactive, in search of a community".

It doesn't matter much either way. We all see the handwriting on the wall.


COMMONS TLP

As for the Jakarta Commons TLP proposal, essentially, that vote
passed. The people who made the proposal could submit it at the next
board meeting as it stands, with a mention that there was some
amicable discussion on the vote thread. As Torsten mentioned, the
volunteers making the proposal might decide to use a more qualified
name than "Apache Commons", so as to resolve the discussion points.

Worse case, the Commons group could always go with "Apache Jakarta
Commons". No one has objected to the re-use of the word "Jakarta", and
more than one person has affirmed that it could be used. Then one
day, we could also have an Apache Ruby Commons, and/or an Apache
DotNet Commons, and maybe even an Apache XML Commons and Apache
WebServers Commons.

The codebase could stay under the Jakarta host for now, or more under
the Apache Commons host. It doesn't much matter. Implementation
details are up to the people doing the work (meaning, the proposed
Jakarta Commons PMC and Infrastructure).

-Ted.

Re: ad "dormant" code: what about "matured" code? (Re: [PROPOSAL] The future of

On 5/21/07, Rony G. Flatscher wrote:
> There may be many reasons why a project turned "dormant": no interest
> (dead technology), committers having gone astray, etc.
>
> One reason that may be special is a project which got developed, is
> used, but there is no reason to develop it further. If classifying a
> project as "matured" it still may need fixing of problems and/or
> enhancements over time, making it necessary to create a new distribution.
>
> The idea of putting a "matured" project into the "incubator" realm does
> not sound "right" to me.

That's is *not* what is being said.

What is being said is that if a codebase loses all of its committers,
and there is no one to nominate new committers, and one or more new
volunteers come along that want to work on the codebase, then those
individuals could become committers by applying to the Incubator.

Anyone who is the position where they have become the last one or two
committers to a codebase should put out a bulletin, first asking for
other ASF Committers to step up, and if no one replies, then
nominating likely candidates from the user list.


> Unless there are already rules that mandate that projects that got
> developed to a point after which they go into "maintenance" mode need to
> go into the "incubator", I would suggest to create a new classification
> for such projects.

Again, no one is suggesting that any codebase be unilaterally moved anywhere.

If we are short of committers for a codebase, then what committers
remain should recruit new committers.

If we lose all the committers, and new volunteers come along, then the
Incubator becomes the way that we bootstrap the new set of committers.
When we realize that have no committers, for whatever reason, then
someone should patch the website so that everyone knows where we
stand.

-Ted.

Re: [PROPOSAL] The future of Jakarta

On 5/21/07, Ted Husted wrote:

> If someone wants to turn Jakarta into a Java portal, then turn Jakarta
> into a Java portal. Some of the codebases may still be under the
> Jakarta PMC umbrella, but would have little effect on using the
> Jakarta site as a portal to the ASF's Java assets.

Ok "Ownership" is perhaps the wrong word, if Jakarta is being
disbanded who provides the oversight?


> Anyone interested in such a thing can start now. There's no need for a
> vote.

But it is under the auspices of the Jakarta PMC, I though there was a
reluctance to see the jakarta PMC retained just for managing these
resources?


d.

RE: [PROPOSAL] The future of Jakarta

Here's a stupid but important question - what impact will all this have =
on the future development of Tomcat?
Thanks,
Brian

-----Original Message-----
From: sa3ruby@gmail.com [mailto:sa3ruby@gmail.com] On Behalf Of Sam Ruby
Sent: Monday, May 21, 2007 8:12 AM
To: Jakarta General List
Subject: Re: [PROPOSAL] The future of Jakarta

On 5/21/07, Jörg Schaible wrote:
>
> But to recap, we had
>
> 1/ Open-up Jakarta to all committers, was vetoed
> 2/ Merge commons into Jakarta, was vetoed
> 3/ Move commons into own TLP, was vetoed

Each of those proposals could be voted down, but are not subject to
veto. In other words, a -1 expressed in such a vote is just a -1, not
a veto.

> Any Jakarta project that feels uneasy because it
> - has an isolated community
> - has a broader scope than "Java"
> should consider a TLP

+1

- Sam Ruby

------------------------------------------------------------ ---------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org

Re: [PROPOSAL] The future of Jakarta

None - Tomcat is its own TLP

-Tim

Guy_Brian@emc.com wrote:
> Here's a stupid but important question - what impact will all this have on the future development of Tomcat?

Re: [PROPOSAL] The future of Jakarta

On 5/21/07, Danny Angus wrote:
> Ok "Ownership" is perhaps the wrong word, if Jakarta is being
> disbanded who provides the oversight?

The same people who provide oversight for any ASF project: The people
doing the work.

If anyone wants Jakarta to be the ASF portal to all of our Java
assets, then make it so.

A commit is the only vote that counts.

-Ted.

Re: [PROPOSAL] The future of Jakarta

Ted Husted wrote:

> Worse case, the Commons group could always go with "Apache Jakarta
> Commons". No one has objected to the re-use of the word "Jakarta", and
> more than one person has affirmed that it could be used.

That *you* don't see a problem in using the Jakarta name, doesn't mean no one has expressed
objections (you even responded to those objections)

Mvgr,
Martin

Re: [PROPOSAL] The future of Jakarta

On 5/21/07, Ted Husted wrote:
> On 5/21/07, Danny Angus wrote:
> > Ok "Ownership" is perhaps the wrong word, if Jakarta is being
> > disbanded who provides the oversight?
>
> The same people who provide oversight for any ASF project: The people
> doing the work.
>
> If anyone wants Jakarta to be the ASF portal to all of our Java
> assets, then make it so.
>
> A commit is the only vote that counts.

Yes, OK, and that's what I'm trying to find out. Does anyone? or is it just me?
If its just me then even without my customary modesty I'd struggle to
imagine that I could provide a sensible level of attention, this
requires some degree of support or we're just flogging a dead horse.
I'm trying to find out whether or not it is even worth drafting a
vote, or if we just want to all go home once the last active
sub-projects get their TLP.

d.

Re: [PROPOSAL] The future of Jakarta

On 5/21/07, Martin van den Bemt wrote:
> That *you* don't see a problem in using the Jakarta name, doesn't mean no one has
> expressed objections (you even responded to those objections)

Yes, I looked back over the thread, and I stand corrected. You did say
that the use of the Jakarta name in another TLP seemed premature. Do
you still feel that way?

-Ted.

Re: [PROPOSAL] The future of Jakarta

Danny Angus wrote:
> On 5/21/07, Ted Husted wrote:
>> On 5/21/07, Danny Angus wrote:
>> > Ok "Ownership" is perhaps the wrong word, if Jakarta is being
>> > disbanded who provides the oversight?
>>
>> The same people who provide oversight for any ASF project: The people
>> doing the work.
>>
>> If anyone wants Jakarta to be the ASF portal to all of our Java
>> assets, then make it so.
>>
>> A commit is the only vote that counts.
>
> Yes, OK, and that's what I'm trying to find out. Does anyone? or is it
> just me?

It's not just you :) It's just too early to do that at this stage, since if it is just some commits
as Teds says, it will be a dead horse. I don't need something formal or something, but at least get
some attention from the java projects out there if they are willing to help out and also have some
collaboration with David Reid / projects.a.o. It's not worth it if the Apache java projects don't
like the idea and help out at least with their project.
(not suggesting you are of a different opinion though Danny)

Mvgr,
Martin

Re: [PROPOSAL] The future of Jakarta

On 5/21/07, Martin van den Bemt wrote:
> It's not just you :) It's just too early to do that at this stage, since if it is just some
> commits
> as Teds says, it will be a dead horse. I don't need something formal or something, but at
> least get
> some attention from the java projects out there if they are willing to help out and also
> have some
> collaboration with David Reid / projects.a.o. It's not worth it if the Apache java projects
> don't
> like the idea and help out at least with their project.
> (not suggesting you are of a different opinion though Danny)

Then take it to the next stage. Update the Jakarta home page to
include links to our other Java products that were never part of
Jakarta, like iBATIS, and invite all ASF Java products to use our news
feed. Open the door, and see if anyone walks in.

-Ted.

Re: [PROPOSAL] The future of Jakarta

Ted Husted wrote:
> On 5/21/07, Martin van den Bemt wrote:
>> It's not just you :) It's just too early to do that at this stage,
>> since if it is just some
>> commits
>> as Teds says, it will be a dead horse. I don't need something formal
>> or something, but at
>> least get
>> some attention from the java projects out there if they are willing to
>> help out and also
>> have some
>> collaboration with David Reid / projects.a.o. It's not worth it if the
>> Apache java projects
>> don't
>> like the idea and help out at least with their project.
>> (not suggesting you are of a different opinion though Danny)
>
> Then take it to the next stage. Update the Jakarta home page to
> include links to our other Java products that were never part of
> Jakarta, like iBATIS, and invite all ASF Java products to use our news
> feed. Open the door, and see if anyone walks in.
>

I am on a different schedule, volunteering on my own terms. In my view doing this now is *way* too
premature. I currently only want to invest my time and energy on Jakarta and it's current projects.

Mvgr,
Martin

Re: [PROPOSAL] The future of Jakarta

Yep still feel that way. Projects that want to use the Jakarta name, should just stay here till they
are the only one left and after that re-establish the Jakarta Project.

Mvgr,
Martin

Ted Husted wrote:
> On 5/21/07, Martin van den Bemt wrote:
>> That *you* don't see a problem in using the Jakarta name, doesn't mean
>> no one has
>> expressed objections (you even responded to those objections)
>
> Yes, I looked back over the thread, and I stand corrected. You did say
> that the use of the Jakarta name in another TLP seemed premature. Do
> you still feel that way?
>
> -Ted.
>
> ------------------------------------------------------------ ---------
> To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: general-help@jakarta.apache.org
>
>
>

Re: [PROPOSAL] The future of Jakarta

What if the proposal were to create the TLP for the purpose of
reporting directly to the board, but nothing else changed? Would the
project name "Apache Jakarta Commons" still be a problem for you if
the physical infrastructure remained "here", under the Jakarta
hostname?

-Ted.

On 5/21/07, Martin van den Bemt wrote:
> Yep still feel that way. Projects that want to use the Jakarta name, should just stay here
> till they
> are the only one left and after that re-establish the Jakarta Project.
>
> Mvgr,
> Martin
>
> Ted Husted wrote:
> > On 5/21/07, Martin van den Bemt wrote:
> >> That *you* don't see a problem in using the Jakarta name, doesn't mean
> >> no one has
> >> expressed objections (you even responded to those objections)
> >
> > Yes, I looked back over the thread, and I stand corrected. You did say
> > that the use of the Jakarta name in another TLP seemed premature. Do
> > you still feel that way?
> >
> > -Ted.

Re: [PROPOSAL] The future of Jakarta

On 5/21/07, Martin van den Bemt wrote:
> > Then take it to the next stage. Update the Jakarta home page to
> > include links to our other Java products that were never part of
> > Jakarta, like iBATIS, and invite all ASF Java products to use our news
> > feed. Open the door, and see if anyone walks in.
>
> I am on a different schedule, volunteering on my own terms. In my view doing this now is
> *way* too premature. I currently only want to invest my time and energy on Jakarta and
> it's current projects.

That's fair. Every volunteer should scratch their own itch :)

If other volunteers were ready to explore this course of action now,
would you object to someone creating a "java@apache" portal here by
extending the Jakarta home page?

-Ted.

Re: [PROPOSAL] The future of Jakarta

On 5/21/07, Ted Husted wrote:
> On 5/21/07, Martin van den Bemt wrote:
> > > Then take it to the next stage. Update the Jakarta home page to
> > > include links to our other Java products that were never part of
> > > Jakarta, like iBATIS, and invite all ASF Java products to use our news
> > > feed. Open the door, and see if anyone walks in.
> >
> > I am on a different schedule, volunteering on my own terms. In my view doing this now is
> > *way* too premature. I currently only want to invest my time and energy on Jakarta and
> > it's current projects.
>
> That's fair. Every volunteer should scratch their own itch :)
>
> If other volunteers were ready to explore this course of action now,
> would you object to someone creating a "java@apache" portal here by
> extending the Jakarta home page?

Easy enough to do; resurrect this page and start adding to it :)

http://svn.apache.org/viewvc/jakarta/site/xdocs/site/java_at _apache.xml?view=log&pathrev=482036

Hen

Re: [PROPOSAL] The future of Jakarta

One link to a separate page isn't a problem, since I prefer that no major changes happen to the main
site at this stage.
Currently I am pretty much dedicated in keeping Jakarta as a brand. And when that time comes to
worry about that, I'll work with the people who still have the itch and the cycles to spare.
Starting to make it happen now feels like a waste of time, since the future of Jakarta is by no way
set at this moment.

Mvgr,
Martin

Ted Husted wrote:
> On 5/21/07, Martin van den Bemt wrote:
>> > Then take it to the next stage. Update the Jakarta home page to
>> > include links to our other Java products that were never part of
>> > Jakarta, like iBATIS, and invite all ASF Java products to use our news
>> > feed. Open the door, and see if anyone walks in.
>>
>> I am on a different schedule, volunteering on my own terms. In my view
>> doing this now is
>> *way* too premature. I currently only want to invest my time and
>> energy on Jakarta and
>> it's current projects.
>
> That's fair. Every volunteer should scratch their own itch :)
>
> If other volunteers were ready to explore this course of action now,
> would you object to someone creating a "java@apache" portal here by
> extending the Jakarta home page?
>
> -Ted.
>
> ------------------------------------------------------------ ---------
> To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: general-help@jakarta.apache.org
>
>
>

Re: [PROPOSAL] The future of Jakarta

That's quite problematic : Jakarta is responsible for jakarta.apache.org, not commons, sharing that
responsibility will just complicate things a lot.

It's pretty simple to solve this though (even though repeating myself here) : Let (a flattened)
commons become Jakarta..

Mvgr,
Martin

Ted Husted wrote:
> What if the proposal were to create the TLP for the purpose of
> reporting directly to the board, but nothing else changed? Would the
> project name "Apache Jakarta Commons" still be a problem for you if
> the physical infrastructure remained "here", under the Jakarta
> hostname?
>
> -Ted.
>
> On 5/21/07, Martin van den Bemt wrote:
>> Yep still feel that way. Projects that want to use the Jakarta name,
>> should just stay here
>> till they
>> are the only one left and after that re-establish the Jakarta Project.
>>
>> Mvgr,
>> Martin
>>
>> Ted Husted wrote:
>> > On 5/21/07, Martin van den Bemt wrote:
>> >> That *you* don't see a problem in using the Jakarta name, doesn't mean
>> >> no one has
>> >> expressed objections (you even responded to those objections)
>> >
>> > Yes, I looked back over the thread, and I stand corrected. You did say
>> > that the use of the Jakarta name in another TLP seemed premature. Do
>> > you still feel that way?
>> >
>> > -Ted.
>
> ------------------------------------------------------------ ---------
> To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: general-help@jakarta.apache.org
>
>
>

Re: [PROPOSAL] The future of Jakarta

On 5/21/07, Martin van den Bemt wrote:
> One link to a separate page isn't a problem, since I prefer that no major changes happen
> to the main site at this stage.
> Currently I am pretty much dedicated in keeping Jakarta as a brand. And when that time
> comes to worry about that, I'll work with the people who still have the itch and the cycles
> to spare. Starting to make it happen now feels like a waste of time, since the future of
> Jakarta is by no way set at this moment.

Why does it have to be and either/or proposition?

I would think that regardless of what anyone envisions the future of
Jakarta to be, extending the home page to highlight *all* of the Java
products at the ASF would be a Good Thing.

The notion of extending the Jakarta home page so that it can become
the focal point of all things Java at Apache seems orthogonal as to
whether or not Jakarta continues to host subprojects.

-Ted.

Re: [PROPOSAL] The future of Jakarta

On 5/21/07, Martin van den Bemt wrote:
> It's pretty simple to solve this though (even though repeating myself here) : Let (a
> flattened) commons become Jakarta..

Then why the concern about the use of Apache Jakarta Commons as a project name?

When the time comes, we could just point at
.

-Ted.

Re: [PROPOSAL] The future of Jakarta

On 5/21/07, Ted Husted wrote:
> On 5/21/07, Martin van den Bemt wrote:
> > It's pretty simple to solve this though (even though repeating myself here) : Let (a
> > flattened) commons become Jakarta..

Actually, it might be helpful if you repeated yourself in full, to be
sure we're not talking past each other. For example, I don't know what
"flattened" means.

-Ted.

Re: [PROPOSAL] The future of Jakarta

Ted Husted wrote:
> On 5/21/07, Martin van den Bemt wrote:
>> One link to a separate page isn't a problem, since I prefer that no
>> major changes happen
>> to the main site at this stage.
>> Currently I am pretty much dedicated in keeping Jakarta as a brand.
>> And when that time
>> comes to worry about that, I'll work with the people who still have
>> the itch and the cycles
>> to spare. Starting to make it happen now feels like a waste of time,
>> since the future of
>> Jakarta is by no way set at this moment.
>
> Why does it have to be and either/or proposition?
>
> I would think that regardless of what anyone envisions the future of
> Jakarta to be, extending the home page to highlight *all* of the Java
> products at the ASF would be a Good Thing.

It's a good thing, but not now :)

>
> The notion of extending the Jakarta home page so that it can become
> the focal point of all things Java at Apache seems orthogonal as to
> whether or not Jakarta continues to host subprojects.

It just removes focus from the tasks we have to deal with *now*.. And if Jakarta is going to still
be a project with code, I rather see the people involved in that project make the decisions.

Don't forget there are 2 outcomes for Jakarta (ignoring no Jakarta at all)
- Jakarta as just a website.
- Jakarta as a real Apache project, which means that project owns Jakarta. Since the Jakarta project
needs to be re-established, the current people on the PMC are not the people on the new PMC and can
therefor have a different opinion on being java at apache and undo all the work.


Mvgr,
Martin

Re: [PROPOSAL] The future of Jakarta

Flattened means : jakarta.apache.org/commons becomes jakarta.apache.org :)

Mvgr,
Martin

Ted Husted wrote:
> On 5/21/07, Ted Husted wrote:
>> On 5/21/07, Martin van den Bemt wrote:
>> > It's pretty simple to solve this though (even though repeating
>> myself here) : Let (a
>> > flattened) commons become Jakarta..
>
> Actually, it might be helpful if you repeated yourself in full, to be
> sure we're not talking past each other. For example, I don't know what
> "flattened" means.
>
> -Ted.
>
> ------------------------------------------------------------ ---------
> To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: general-help@jakarta.apache.org
>
>
>

Re: [PROPOSAL] The future of Jakarta

Ted Husted wrote:
> On 5/21/07, Martin van den Bemt wrote:
>> It's pretty simple to solve this though (even though repeating myself
>> here) : Let (a
>> flattened) commons become Jakarta..
>
> Then why the concern about the use of Apache Jakarta Commons as a
> project name?
>
> When the time comes, we could just point at
> .
>

I am highly opposed to that because of the following reasons :

- If commons wants to be Jakarta they just should work *here* to achieve that.
- If commons is leaving to come back, they are just ignoring the other projects that are still here.
- It is solving the problem the wrong way
- The biggest (developer) community is in commons. We need them to still care and think about the
rest of Jakarta.

It's just like leaving your parent's home to live on your own to run away from your siblings and
then try to move back in when the siblings left the parental home. Big chance your parents will not
let you do that.

Going to bed now..

Mvgr,
Martin

RE: [PROPOSAL] The future of Jakarta

Martin van den Bemt wrote on Tuesday, May 22, 2007 2:16 AM:

> That's quite problematic : Jakarta is responsible for
> jakarta.apache.org, not commons, sharing that
> responsibility will just complicate things a lot.
>=20
> It's pretty simple to solve this though (even though
> repeating myself here) : Let (a flattened)
> commons become Jakarta..

+1

We have the brand and lot of people do not even recognize that Jakarta =
Commons !=3D Jakarta (nor do they probably care). Especially now that =
most of the original jakarta projects went to TLPs. Assimilate the rest =
in one flat hierarchy.

- Jörg

Re: [PROPOSAL] The future of Jakarta

On 5/22/07, Martin van den Bemt wrote:

> It's pretty simple to solve this though (even though repeating myself here) : Let (a flattened)
> commons become Jakarta..

I thought that that idea was unpopular with some commons commiters on this PMC?

d.

Re: [PROPOSAL] The future of Jakarta

On 5/22/07, Danny Angus wrote:
> On 5/22/07, Martin van den Bemt wrote:
>
> > It's pretty simple to solve this though (even though repeating myself here) : Let (a flattened)
> > commons become Jakarta..
>
> I thought that that idea was unpopular with some commons commiters on this PMC?

I'm a Commons Committer (although not active lately, nor likely to be
again soon because of other personal interests, so take this for what
it's worth) ... but I always assumed that what Martin describes
(commons becomes Jakarta) was the natural endgame when you've
encouraged all the active subprojects that should be TLPs to do so,
and dealt appropriately with dormant/dead/inactive codebases.

The only other reasonable alternative would seem to mean sending
Commons somewhere else and retiring the Jakarta name. That doesn't
make marketing sense to me ... although (even though I have a Business
Admin degree, Marketing was definitely my least favorite subject :-)

On the other hand, are there enough Commons committers (across *all*
the libraries) to matter (i.e. create a viable "community"), or should
we just consider the whole thing an exercise that has come to a
natural conclusion (a bunch of mature code, and a bunch of experiments
that never attracted much community) and call it a day?

If Commons is still viable, then Commons -> Jakarta only makes sense,
and the sooner the better to minize user confusion. Otherwise, the
discussion of what to do next seems a bit academic.

Craig

PS: Yes, of course, there are passionate believers in the development
of particular libraries. Are there enough to make a viable community
for *any* of the libraries on their own? Or enough that care about
the Commons ecosystem as a whole to satisfy Apache's notions of
"community"? It is not clear to me (any longer) that a "commons" type
environment fits Apache culture (as it is currently being discussed)
at all.

Re: [PROPOSAL] The future of Jakarta

On 5/22/07, Danny Angus wrote:
> On 5/22/07, Martin van den Bemt wrote:
>
> > It's pretty simple to solve this though (even though repeating myself here) : Let (a flattened)
> > commons become Jakarta..
>
> I thought that that idea was unpopular with some commons commiters on this PMC?

With POI and Turbine going TLP, we are left with the Commons and
eleven other subprojects

* BCEL
* BSF
* Cactus
* ECS
* HttpComponents
* JCS
* JMeter
* ORO
* Regexp
* Slide
* Taglibs

I don't think any of these would be out-of-scope for the Commons, but
there is the issue of whether we have maintenance Committers for all
eleven. We've always resisted the ASF becoming a "dumping ground",
and we don't want start dumping on each other. :)

I wonder if Torsten and the rest of the Commons group would be open to
inviting the remaining subprojects to join the Commons. The key being
whether there is anyone left who is both willing and able to accept
the invitation :)

If any subprojects then remain, we could update the websites of any
inactive subprojects to say that they are inactive, and then
re-establish the Jakarta PMC with the individuals listed on the
Commons resolution, plus the committers for any subprojects that join
the Commons, plus the committers for any active subprojects that do
not want to join the Commons at this time.

Any remaining active subprojects could designate a PMC contact who
would be responsible for reporting to the Jakarta PMC on a quarterly
basis, even if to say "All is well". If the reports stop, the Jakarta
PMC could mark the subproject "inactive - in search of committers". If
anyone wishes to become a committer to an inactive subproject, the
recourse would be to apply to the Incubator.

-Ted.

Re: [PROPOSAL] The future of Jakarta

On 5/22/07, Craig McClanahan wrote:
> PS: Yes, of course, there are passionate believers in the development
> of particular libraries. Are there enough to make a viable community
> for *any* of the libraries on their own? Or enough that care about
> the Commons ecosystem as a whole to satisfy Apache's notions of
> "community"? It is not clear to me (any longer) that a "commons" type
> environment fits Apache culture (as it is currently being discussed)
> at all.

You're right, it probably doesn't. Towards that end, we should encourage
Commons components with robust communities to apply for top-level
status, so that they can report directly to the Board and have their
own mailing lists. The "one list" rule is a great equalizer and should
help keep the Commons from becoming another Jakarta.

To support smaller communities throughout the ASF, we may need to
adjust our notion of Committer and PMC Member to include not only
people who can write and apply patches, but to embrace power users
too.

-Ted.

Re: [PROPOSAL] The future of Jakarta

----- Original Message ----
From: Ted Husted
On 5/22/07, Craig McClanahan wrote:
> > PS: Yes, of course, there are passionate believers in the development
> > of particular libraries. Are there enough to make a viable community
> > for *any* of the libraries on their own? Or enough that care about
> > the Commons ecosystem as a whole to satisfy Apache's notions of
> > "community"? It is not clear to me (any longer) that a "commons" type
> > environment fits Apache culture (as it is currently being discussed)
> > at all.
>
> You're right, it probably doesn't. Towards that end, we should encourage
> Commons components with robust communities to apply for top-level
> status, so that they can report directly to the Board and have their
> own mailing lists. The "one list" rule is a great equalizer and should
> help keep the Commons from becoming another Jakarta.

Huh? Commons has one mailing list. Each of its components are not isolated islands suitable for TLP, but part of the shared commons identity. They are not Jakarta style subprojects.

Note that there are cliques within commons, some people care about one set of components, other people care about another set of components. Thats OK. We can all commit, we can all vote, we can all comment on the mailing list.

This approach of commons is different to the rest of the ASF, but it does work (and is probably the only way to support small codebases within the ASF. I also believe it is sufficiently different to how the other projects in Jakarta have been run to make merging not necessarily smooth.

In summary:
a) I believe the status quo is not viable
b) I believe that merging commons into Jakarta merges two mismatched groups
c) I believe that commons is big enough and strong enough to be a TLP

So, I support Apache Commons TLP - Just as Tomcat grew up and left the Jakarta brand name, so should Commons. But we should assert our right for that to be Java only - we really did get the name first, and the commons community (one-list, one-pmc) is fundamentally tied to Java.

Stephen

RE: [PROPOSAL] The future of Jakarta

Hi Stephen,

Stephen Colebourne wrote on Tuesday, May 22, 2007 2:43 PM:

[snip]

> In summary:
> a) I believe the status quo is not viable
> b) I believe that merging commons into Jakarta merges two
> mismatched groups
> c) I believe that commons is big enough and strong enough to be a TLP
>=20
> So, I support Apache Commons TLP - Just as Tomcat grew up and
> left the Jakarta brand name, so should Commons. But we should
> assert our right for that to be Java only - we really did get
> the name first, and the commons community (one-list, one-pmc)
> is fundamentally tied to Java.

The point is (b). Is it really that different: A merged jakarta commons =
vs. commons alone? Commons has also some projects with different weight. =
Compare lang and digester. Any current Jakarta project that feels uneasy =
with such an absorbtion (possibly HttpComponnets, Taglibs ??), may head =
for an own TLP. All the others will not make much difference - since =
there are view committers left and most of them have dwindling =
communities. Additionally most of the left ones fit quite good into =
commons like oro, regexp, ECS, ...

- Jörg

Re: [PROPOSAL] The future of Jakarta

On 5/22/07, Stephen Colebourne wrote:
>
> In summary:
> a) I believe the status quo is not viable
> b) I believe that merging commons into Jakarta merges two mismatched groups

My suggestion was to merge the Jakarta subprojects into the Commons,
not the other way around.

* The remaining subprojects all seem to be "reusable components"
within the scope of the Commons charter.

* If the remaining subprojects join the Jakarta Commons, then we could
then ask the board to re-establish the Jakarta PMC, using the list
suggested in the draft resolution as the initial PMC.

* The extended Commons group then becomes the new Jakarta PMC.

* The page becomes the
Jakarta home page, and we change the first sentence there to read "The
Jakarta Commons project is focused on all aspects of reusable Java
components.".

In the alternative, without an anchor subproject, or a ready
initiative to promote Java at Apache, realistically, Jakarta whithers
away.

-Ted.

Re: [PROPOSAL] The future of Jakarta

----- Original Message ----
From: Ted Husted
> On 5/22/07, Stephen Colebourne wrote:
> > In summary:
> > a) I believe the status quo is not viable
> > b) I believe that merging commons into Jakarta merges two mismatched groups
>
> My suggestion was to merge the Jakarta subprojects into the Commons,
> not the other way around.

Yes, Jakarta subprojects should be invited to join Commons. I'll happily welcome them to the Commons fold.

But *invited* is the key word. They must not be forced - isn't the ASF about 'community'? For me that means not pushing groups to go where they don't want to go.

> * The remaining subprojects all seem to be "reusable components"
> within the scope of the Commons charter.

Mostly, but that doesn't mean that they don't have their own communities (even a community of one). They mustn't be forced to do anything. Encouraged perhaps, not forced.

> * If the remaining subprojects join the Jakarta Commons, then we could
> then ask the board to re-establish the Jakarta PMC, using the list
> suggested in the draft resolution as the initial PMC.
>
> * The extended Commons group then becomes the new Jakarta PMC.

This seems complicated, political, and unecessary. We have a vibrant community in Commons, and for some half-arsed reason we seem to be trying to abuse it's strength to save long-dead Jakarta.

I know some people here have long attachments to 'Jakarta', and the perceived 'brand'. I don't. (At one time I did want to save Jakarta, but then I saw how much of a disfunctional beast it had become). Jakarta is like a family, where the children have left home and have their own lives now.

Commons has its own life too. Its own community. And that's independent of Jakarta. There is no need to have a Jakarta PMC overseeing Commons. In fact, I object to the fact the it seems to be so difficult to escape Jakarta.

To those trying to preserve Jakarta I say 'let go of Commons'. Don't abuse Commons to try and save Jakarta. If the Jakarta name is worth saving, people and community will form to save it. If not, then it will die. Thats normal and natural.

> In the alternative, without an anchor subproject, or a ready
> initiative to promote Java at Apache, realistically, Jakarta whithers away.

I'd encourage people to step back for a moment and look at what Jakarta actually is today. Its a very disparate group of voices pulling in different directions. This is a natural result of the true meaning of Jakarta - the community around the code - leaving. There is no longer any focus within Jakarta. Nor has there been for a *very* long time.

Whatever Jakarta becomes once Commons leaves is up to Jakarta, and those who feel it should exist. Just don't abuse Commons to try and save Jakarta.

Stephen

Re: [PROPOSAL] The future of Jakarta

On 5/23/07, Stephen Colebourne wrote:
> ----- Original Message ----
> From: Ted Husted
> > On 5/22/07, Stephen Colebourne wrote:
> > > In summary:
> > > a) I believe the status quo is not viable
> > > b) I believe that merging commons into Jakarta merges two mismatched groups
> >
> > My suggestion was to merge the Jakarta subprojects into the Commons,
> > not the other way around.
>
> Yes, Jakarta subprojects should be invited to join Commons. I'll happily welcome them to the Commons fold.
>
> But *invited* is the key word. They must not be forced - isn't the ASF about 'community'? For me that means not pushing groups to go where they don't want to go.
>
> > * The remaining subprojects all seem to be "reusable components"
> > within the scope of the Commons charter.
>
> Mostly, but that doesn't mean that they don't have their own communities (even a community of one). They mustn't be forced to do anything. Encouraged perhaps, not forced.
>
> > * If the remaining subprojects join the Jakarta Commons, then we could
> > then ask the board to re-establish the Jakarta PMC, using the list
> > suggested in the draft resolution as the initial PMC.
> >
> > * The extended Commons group then becomes the new Jakarta PMC.
>
> This seems complicated, political, and unecessary. We have a vibrant community in Commons, and for some half-arsed reason we seem to be trying to abuse it's strength to save long-dead Jakarta.
>
> I know some people here have long attachments to 'Jakarta', and the perceived 'brand'. I don't. (At one time I did want to save Jakarta, but then I saw how much of a disfunctional beast it had become). Jakarta is like a family, where the children have left home and have their own lives now.
>
> Commons has its own life too. Its own community. And that's independent of Jakarta. There is no need to have a Jakarta PMC overseeing Commons. In fact, I object to the fact the it seems to be so difficult to escape Jakarta.
>
> To those trying to preserve Jakarta I say 'let go of Commons'. Don't abuse Commons to try and save Jakarta. If the Jakarta name is worth saving, people and community will form to save it. If not, then it will die. Thats normal and natural.
>
> > In the alternative, without an anchor subproject, or a ready
> > initiative to promote Java at Apache, realistically, Jakarta whithers away.
>
> I'd encourage people to step back for a moment and look at what Jakarta actually is today. Its a very disparate group of voices pulling in different directions. This is a natural result of the true meaning of Jakarta - the community around the code - leaving. There is no longer any focus within Jakarta. Nor has there been for a *very* long time.
>
> Whatever Jakarta becomes once Commons leaves is up to Jakarta, and those who feel it should exist. Just don't abuse Commons to try and save Jakarta.

I agree that Commons shouldn't be burdoned with solving the Jakarta
issues - it should have its own PMC and be in control of the space it
operates in. Maybe the remaining sub-projects need to do something
similar - put together a TLP proposal - with the idea that they group
togther like Commons (single dev/user mailing list) to give each other
oversight.

Niall

> Stephen

Re: [PROPOSAL] The future of Jakarta

>
> To those trying to preserve Jakarta I say 'let go of Commons'. Don't abuse Commons to try and save Jakarta. If the Jakarta name is worth saving, people and community will form to save it. If not, then it will die. Thats normal and natural.
>

Maybe not a reference to me, but in case it is, a reaction is probably needed. I am not abusing
commons to save Jakarta. I just don't want commons to claim the Jakarta name when it leaves, since
that would be abusing the other projects still present at Jakarta.

That's what my notes are about : if the commons goal is to become Jakarta, you shouldn't leave. (not
saying that this is what you wanted, just my observation from the threads going on)

Mvgr,
Martin

Re: [PROPOSAL] The future of Jakarta

On 5/23/07, Stephen Colebourne wrote:
> In fact, I object to the fact the it seems to be so difficult to escape Jakarta.

:) So far, it's been *much* less difficult than creating the Jakarta
Commons in the first place! Back in the day, we actually had a
separate mailing list just for for the discussions about whether to
create the subproject, and how it would work if we did! :)

So far, the TLP resolution quickly passed by a landslide. Two of us
had reservations about an "Apache Commons" project that's devoted to
Java, as opposed to an "Apache [Java|Jakarta|Mocha|J] Commons" that's
devoted to Java. There were two other negative votes for different
reasons, and almost thirty votes in the affirmative.

Meanwhile, some of us have pointed out that the other remaining
subprojects are within the scope of the Jakarta Commons, and have
wondered if these subprojects would now like to join the commons. Of
course, that could happen before or after the proposed resolution is
offered to the board. But, if it did happen first, that change would
remove any complaint as to using Apache Jakarta Commons as a project
name.

From the beginning, the intent was to submit the proposed resolution
to the June board meeting. There's time yet to see if the other
subprojects want to join, so nothing is being delayed.


> I'd encourage people to step back for a moment and look at what Jakarta actually is
> today. Its a very disparate group of voices pulling in different directions. This is a natural
> result of the true meaning of Jakarta - the community around the code - leaving. There is
> no longer any focus within Jakarta. Nor has there been for a *very* long time.

Ummm, you may be confusing cause and effect. Jakarta has been " very
disparate group of voices pulling in different directions" for as long
as I've been here, which would be going on seven years. :)

-Ted.

Re: [PROPOSAL] The future of Jakarta

On 5/25/07, Ted Husted wrote:
> On 5/23/07, Stephen Colebourne wrote:
> > In fact, I object to the fact the it seems to be so difficult to escape Jakarta.
>
> :) So far, it's been *much* less difficult than creating the Jakarta
> Commons in the first place! Back in the day, we actually had a
> separate mailing list just for for the discussions about whether to
> create the subproject, and how it would work if we did! :)

:)

> So far, the TLP resolution quickly passed by a landslide. Two of us
> had reservations about an "Apache Commons" project that's devoted to
> Java, as opposed to an "Apache [Java|Jakarta|Mocha|J] Commons" that's
> devoted to Java. There were two other negative votes for different
> reasons, and almost thirty votes in the affirmative.
>
> Meanwhile, some of us have pointed out that the other remaining
> subprojects are within the scope of the Jakarta Commons, and have
> wondered if these subprojects would now like to join the commons. Of
> course, that could happen before or after the proposed resolution is
> offered to the board. But, if it did happen first, that change would
> remove any complaint as to using Apache Jakarta Commons as a project
> name.
>
> From the beginning, the intent was to submit the proposed resolution
> to the June board meeting. There's time yet to see if the other
> subprojects want to join, so nothing is being delayed.

*nod*

I think we're at a point of needing to offer options to the subprojects:

1) Go TLP (or other TLP)
2) Stay for Jakarta2 (see below)
3) Goto the Incubator - I know this is a very disliked option, but
it's better than the only other option I can think of:
4) Goto code.google. Ack :(

I admit to thinking that the three big question marks in terms of
living in a flattened dev@ list for me are Slide, JMeter and Cactus.
I'm willing to be +1 to them being in a flattened Jakarta2 with an eye
to sending them TLP if we can build community. It's effectively the
Jakarta2 community incubating them, but if it helps things move on...

Jakarta2 - A flattened commons-like umbrella which in terms of change
means a flattened dev@ list and svn changes. What I don't know is
whether people are going to be demanding that the subsites look the
same; ie) need to mavenize each project and adjust the site. The
easiest way to deal with things will be to move the other subprojects
into Commons and reestablish the Project.

Hen

Re: [PROPOSAL] The future of Jakarta

On 5/25/07, Henri Yandell wrote:
> 4) Goto code.google. Ack :(

I wouldn't discount GoogleCode (or Java.net or SourceForge or
CodeHaus). Right now, there's a GoogleCode site that I use everyday,
and it's been utterly reliable. There's features I miss, but the UI is
so convenient, I don't mind. We are not Borg, and not every software
product need live under the ASF umbella.

> Jakarta2 - A flattened commons-like umbrella which in terms of change
> means a flattened dev@ list and svn changes. What I don't know is
> whether people are going to be demanding that the subsites look the
> same; ie) need to mavenize each project and adjust the site. The
> easiest way to deal with things will be to move the other subprojects
> into Commons and reestablish the Project.

This is probably just an unfortunate turn of phrase, but we can't just
"move" anyone anywhere. The Incubator PMC is not going to accept any
code without volunteers to go with it. Likewise, we can't do anything
about the subproject websites without volunteers to do that work too.
But, as a PMC, we could ask infra@ to create a shared mailing lists to
replace the others, and make karma adjustments.

Here's my take-away from Henri's post. The Jakata PMC, as it stands
today, could set a deadline for the remaining subprojects to make
other hosting arrangements (TLP, Commons, Google). Otherwise, on a
date certain, we would create single Jakarta Dev and User lists for
all the remaining subprojects to share, and open karma to all the
subprojects to all the Jakarta committers, in the style of the
Commons.

In other words, create a TLP, join the Commons, or become a commons.

One other alternative would be for the active committers to those
remaining subprojects to draft their own resolution proposal for
creating a new Jakarta PMC, and boot the rest of us out. :) Though, if
anyone wanted to make that happen, I'd suggest making it happen for
the June board meeting, to coincide with the Commons proposal.

-Ted.

Re: [PROPOSAL] The future of Jakarta

On 5/26/07, Ted Husted wrote:
> On 5/25/07, Henri Yandell wrote:
> > 4) Goto code.google. Ack :(
>
> I wouldn't discount GoogleCode (or Java.net or SourceForge or
> CodeHaus). Right now, there's a GoogleCode site that I use everyday,
> and it's been utterly reliable. There's features I miss, but the UI is
> so convenient, I don't mind. We are not Borg, and not every software
> product need live under the ASF umbella.

Ack in terms of driving a community away because it is unable to meet
our arbitrary criteria.

> > Jakarta2 - A flattened commons-like umbrella which in terms of change
> > means a flattened dev@ list and svn changes. What I don't know is
> > whether people are going to be demanding that the subsites look the
> > same; ie) need to mavenize each project and adjust the site. The
> > easiest way to deal with things will be to move the other subprojects
> > into Commons and reestablish the Project.
>
> This is probably just an unfortunate turn of phrase, but we can't just
> "move" anyone anywhere.

Yes we can, we just choose not to. Our PMC has a history of delegating
the decision making to the subprojects, rather than making it for
them; it's not a requirement.

Still - I'm definitely presuming that that will continue. Subprojects
need to be on board. The problem is when a subproject chooses option
5; do nothing. Is that a decision we're happy with.

> The Incubator PMC is not going to accept any code without volunteers to go
> with it.

Things get really easy in that situation - we retire it just like
Alexandria. We've not got any code without community currently.

> Likewise, we can't do anything
> about the subproject websites without volunteers to do that work too.

We can volunteer. (I'll happily go in and change things :) ).

> But, as a PMC, we could ask infra@ to create a shared mailing lists to
> replace the others, and make karma adjustments.
>
> Here's my take-away from Henri's post. The Jakata PMC, as it stands
> today, could set a deadline for the remaining subprojects to make
> other hosting arrangements (TLP, Commons, Google). Otherwise, on a
> date certain, we would create single Jakarta Dev and User lists for
> all the remaining subprojects to share, and open karma to all the
> subprojects to all the Jakarta committers, in the style of the
> Commons.
>
> In other words, create a TLP, join the Commons, or become a commons.
>
> One other alternative would be for the active committers to those
> remaining subprojects to draft their own resolution proposal for
> creating a new Jakarta PMC, and boot the rest of us out. :) Though, if
> anyone wanted to make that happen, I'd suggest making it happen for
> the June board meeting, to coincide with the Commons proposal.

Chiefly, we need to decide if we're sending the Commons proposal. The
board learnt from the Shale/Struts proposal not to accept anything if
the current PMC are not happy with the situation.

Hen

Re: [PROPOSAL] The future of Jakarta

In message <31cc37360705261733n4629c8bbkb0a9044184e5fe93@mail.gmail.com>, "Henr
i Yandell" writes:
>Chiefly, we need to decide if we're sending the Commons proposal. The

We decided already to submit the Commons proposal by virtue of the vote
result. I suggest we uphold the current decision and submit the proposal
in order to make some progress.

daniel

Re: [PROPOSAL] The future of Jakarta

On 5/26/07, Henri Yandell wrote:
> Ack in terms of driving a community away because it is unable to meet
> our arbitrary criteria.

That sort of thinking just seems so Borg to me. It's another way of
saying that a software product only has value if its hosted by the
ASF.

If a subproject, or even a project, is down to one or two committers,
and those committers can't find a third, and don't want to apply to
the Commons or declare the product dormant, then setting up shop on
GoogleCode is an excellent alternative. I've done the same myself, and
it's not the least bit painful. In many ways, it's joyful.

It might even be healthy if more ASF committers were involved with
other hosts. The ASF may be a cult, but it should not also be a fetish
:)

-Ted.

Re: [PROPOSAL] The future of Jakarta

On 5/30/07, Ted Husted wrote:
> On 5/26/07, Henri Yandell wrote:
> > Ack in terms of driving a community away because it is unable to meet
> > our arbitrary criteria.
>
> That sort of thinking just seems so Borg to me. It's another way of
> saying that a software product only has value if its hosted by the
> ASF.
>
> If a subproject, or even a project, is down to one or two committers,
> and those committers can't find a third, and don't want to apply to
> the Commons or declare the product dormant, then setting up shop on
> GoogleCode is an excellent alternative. I've done the same myself, and
> it's not the least bit painful. In many ways, it's joyful.

Which Apache projects have you moved to GoogleCode and found it a
joyful experience? ie) I presume you mean starting a project there
rather than moving a community from the ASF.

My distaste for driving people to an open source repository is not
because of the repositories, but because our rules have driven them
out.

> It might even be healthy if more ASF committers were involved with
> other hosts. The ASF may be a cult, but it should not also be a fetish
> :)

Other communities, not 'host's. ie) You won't learn much from
code.google, java.net or sf.net other than whether you love or hate
the infrastructure. I bet a lot of us are involved with other
communities.

Hen

Re: [PROPOSAL] The future of Jakarta

On 5/30/07, Henri Yandell wrote:
> On 5/30/07, Ted Husted wrote:
> > On 5/26/07, Henri Yandell wrote:
> > > Ack in terms of driving a community away because it is unable to meet
> > > our arbitrary criteria.
> >
> > That sort of thinking just seems so Borg to me. It's another way of
> > saying that a software product only has value if its hosted by the
> > ASF.
> >
> > If a subproject, or even a project, is down to one or two committers,
> > and those committers can't find a third, and don't want to apply to
> > the Commons or declare the product dormant, then setting up shop on
> > GoogleCode is an excellent alternative. I've done the same myself, and
> > it's not the least bit painful. In many ways, it's joyful.
>
> Which Apache projects have you moved to GoogleCode and found it a
> joyful experience? ie) I presume you mean starting a project there
> rather than moving a community from the ASF.
>

I suspect you are missing the point that *I* at least think Ted is
making ... doing open source outside of Apache is fun, if you like
doing open source. Doing open source inside Apache is a pain ... even
if you like doing open source, and even if you are an insider and know
all the loopholes.

> My distaste for driving people to an open source repository is not
> because of the repositories, but because our rules have driven them
> out.
>
> > It might even be healthy if more ASF committers were involved with
> > other hosts. The ASF may be a cult, but it should not also be a fetish
> > :)
>
> Other communities, not 'host's. ie) You won't learn much from
> code.google, java.net or sf.net other than whether you love or hate
> the infrastructure. I bet a lot of us are involved with other
> communities.
>

You're right that it's more community oriented than host oriented
(because it is about the process, not the technology). You are wrong
if you believe that "the Apache Way" (if there is such a singular
thing, which I would dispute based on seven years of evidence to the
contrary) makes things easier rather than harder. Yes, there are some
benefits of the "Apache" brand, but it is an open question whether
they are worth the costs.

For myself, I have lots of ideas to do future open source projects,
and (at the moment) zero plans to do them here at Apache. The
emotional and procedural and cultural costs are too high to compensate
for the branding benefits.

> Hen

Craig

Re: [PROPOSAL] The future of Jakarta

On 5/30/07, Craig McClanahan wrote:
> On 5/30/07, Henri Yandell wrote:
> > On 5/30/07, Ted Husted wrote:
> > > On 5/26/07, Henri Yandell wrote:
> > > > Ack in terms of driving a community away because it is unable to meet
> > > > our arbitrary criteria.
> > >
> > > That sort of thinking just seems so Borg to me. It's another way of
> > > saying that a software product only has value if its hosted by the
> > > ASF.
> > >
> > > If a subproject, or even a project, is down to one or two committers,
> > > and those committers can't find a third, and don't want to apply to
> > > the Commons or declare the product dormant, then setting up shop on
> > > GoogleCode is an excellent alternative. I've done the same myself, and
> > > it's not the least bit painful. In many ways, it's joyful.
> >
> > Which Apache projects have you moved to GoogleCode and found it a
> > joyful experience? ie) I presume you mean starting a project there
> > rather than moving a community from the ASF.
> >
>
> I suspect you are missing the point that *I* at least think Ted is
> making ... doing open source outside of Apache is fun, if you like
> doing open source. Doing open source inside Apache is a pain ... even
> if you like doing open source, and even if you are an insider and know
> all the loopholes.
>
> > My distaste for driving people to an open source repository is not
> > because of the repositories, but because our rules have driven them
> > out.
> >
> > > It might even be healthy if more ASF committers were involved with
> > > other hosts. The ASF may be a cult, but it should not also be a fetish
> > > :)
> >
> > Other communities, not 'host's. ie) You won't learn much from
> > code.google, java.net or sf.net other than whether you love or hate
> > the infrastructure. I bet a lot of us are involved with other
> > communities.
> >
>
> You're right that it's more community oriented than host oriented
> (because it is about the process, not the technology). You are wrong
> if you believe that "the Apache Way" (if there is such a singular
> thing, which I would dispute based on seven years of evidence to the
> contrary) makes things easier rather than harder. Yes, there are some
> benefits of the "Apache" brand, but it is an open question whether
> they are worth the costs.
>
> For myself, I have lots of ideas to do future open source projects,
> and (at the moment) zero plans to do them here at Apache. The
> emotional and procedural and cultural costs are too high to compensate
> for the branding benefits.

Been there (ie: pissed off), done that (ie: grumbled). It's not the
black and white scenario it seems at first. I'm still trying to decide
what it all means to me though, sometimes moving back to the UK near
my parents and finding a nice dull job pushing numbers is so very very
attractive. Brain dump of current thoughts follows...serves you right
:)

---

A bunch of coders took a project written by others, forked it, hacked
around with it and had a lot of success - based primarily on it being
the right time and secondarily on having created a positive atmosphere
to development. They created a foundation to support this development
- its goal to enforce the atmosphere that the first project naturally
evolved to.

A bit later, as the foundation grew beyond their original development,
they didn't like the different cultures that inhabited the foundation
and, effectively, the Apache Way was created to impose a monoculture.
This is imposed by a relatively vague set of memes that are strongly
applied by many members of the community. The preaching of this way
also happily created a set of memes to resist the monoculture advance;
bureaucracy, hypocrisy, arrogance.

---

Definition for the below: "Enterprise Open Source" - the massing of
open source projects into a larger group. Sorry that that phrase
clashes with existing ones, I haven't got a better term yet. Might
just have to be 'Enterprise Foundation'. So - Enterprise meaning
'large collection of smaller entities'.

---

The strongest anti-meme is the anger against enforcement. This is the
primary difference between Codehaus and Apache for example, where
Apache enforces, Codehaus merely recommends. Once you sit down and
identify many of the Apache memes, I don't think open source
committers would be against them. Open source leaders might.

Remember... the ideas in the Apache Way are not reality, they are
unreachable targets.

Idea -> Individuals. Companies don't get to use their bulk to bully
individuals out of the conversation. Employers don't get to strongarm
their employees.

I think we get relatively near the ideal here. I get to walk in to an
interview and when the obligatory Prior Inventions agreement shows up,
I can pull out the CLA and CCLA and get some level of protection. This
is where the enterprise bit helps Apache; employers are going to laugh
when you pull out MyPetProject's CLA. They'll listen if you are
talking about a JBoss, MySQL, Spring or Apache CLA.

Idea -> (Re)leveling playing field. Starting a project doesn't
designate you as forever worthy. You have to be active to remain as
the 'Project Leader'.

We suck at this one. The meme is "There is no such thing as a project
leader", which is bull. There totally are project leaders, but they're
there on merit deigned them by the project community; and I'm sure you
can outlive your merit for a while before an explosion or someone
notices you're absent. Again, a MyPetProject is trickier here. Either
I'm the apparent leader for life and I'm wondering how to reassure
others that I'm not; or I'm wondering whether I trust the current
leader enough to get/stay involved.

Idea -> Legal issues are paid attention to, aka your ass is covered
(somewhat). There are open source projects who distribute non-open
source dependencies without telling you, or whose code could contain
IP they've not vetted etc.

We are on a score-draw on this one. The Apache Way does do well in
terms of enforcing attention, but it's never going to be a replacement
for a user doing their own due diligence and we go over the top and
create bureaucracy. We go over the top because when faced with a legal
issue, only a lawyer is going to consider another option other than
'play it safe'. Plus as things change, it takes forever for people to
discover that things are different and arguments are repeated again
and again (cf: the JCS vote thread). I think the members were
partially intended to help with this spread of information across the
foundation, but I don't think it's working. In fact as they're more
often sure of their knowledge, they're much less likely to read new
documentation (if and when it's written).

[Need to think of more here...]

---

One idea that I think we've failed to find is 'trust'. If some
stranger shows up at MyPetProject, the amount of effort I put them to
making to earn my trust should be less than the amount of effort I put
someone I know to. The Apache concept of having 'done one good thing
and being let in the door' _should_ mean that we make it easier to
give them commit access to our Apache project. We do do that
sometimes, but it's not something we talk about. And it's not far
enough. It should be at the point of "Hey, I want to hack on X";
"Okay, here's the karma". That's something that's worthy of a meme.

---

Benefits of Apache. The easy ones to list are 'brand' and 'TCKs!'.
Then there's a kind of vague one about "companies like Apache stuff"
which is part of the meaning of the brand to people. Either the brand
means Webserver to them and they listen because its the only name they
recognize, or they're aware of the extreme memes of the Apache Way and
they like what they hear (enforcing rules on open source probably
sounds pretty cool to enterprise corporations I think). Admittedly the
more likely answer is that they've never heard of the name anyway.

There are other benefits of the foundation approach.

Good shared infrastructure. The code repositories are good for free,
but they suck for anyone who's got a server and a bit of time to set
things up. Shell account, responsive svn, jira; all of these are
better than the experience I've had at sf and code.google. I've not
used java.net, mostly I just sit and swear at how often they make me
log in for what should be public information.

The trust network I mention above. And the larger network of people
who are moving passed. A tiny corner somewhere with MyPetProject tends
not to get many passers by. This is often a common anti-meme, that it
is somehow unfair that the project at Apache gets more noise and
interest than the one out there on its own; but it's like setting up
shop on a major road or a minor road. The major road is quite simply
more travelled.

The protection of being a part of something much bigger. The chief one
here to my view, which I've mentioned already, is the extra strength
it gives you in your relationship with your employers. I don't know
how well that works for huge employers - employees there can't really
use my line from a few years back of "Hey, the big companies are happy
with their employees committing" :) There's a negative here, something
bigger is a bigger target. Maybe someday we'll all regret the lack of
agility.

---

MyPetProject. It's fun stuff. My current MyPetProject have been a
bunch of JIRA plugins. Because I'm not going to pull off MyPetProject
CLA, they're squarely owned by my employers. They're AL 2.0 though, so
I (or someone else) can fork them anytime. I've not had any mailing
lists, or online svn, I just push out jars and src zips on a website.
People talk to me directly, or they post comments on the Confluence
pages at Atlassian. It's not a good way to build a community, but it's
been enough for my fun.

Once I find a dedicated box to stick things on, I'll setup JIRA, Jive,
Fisheye etc. There's a direct benefit of MyPetProject - I don't have
to deal with hours of crap to get Jive and Fisheye up. And I get to
customize my JIRA heavily without arguing with the rest of you.

Releases. Releases are wonderful. I can release with barely a thought
- and it's not through any Maven magic, I still do it all by hand.
However I don't have to ask anyone for permission. Release? Yes. Okay.
Done. Bugfixes can be back in a JIRA admins hands the evening of their
bug report.

---

Time for family. Suffice to say - definitely a subject I've been
thinking a lot about the last few years. Wtf is Apache, why tf am I
here and how much beer will commons.codehaus.org take ;)

Hen

Re: [PROPOSAL] The future of Jakarta

This is amazing. I agree with Craig on something almost completely.

Craig McClanahan wrote:
> On 5/30/07, Henri Yandell wrote:
>> On 5/30/07, Ted Husted wrote:
>> > On 5/26/07, Henri Yandell wrote:
>> > > Ack in terms of driving a community away because it is unable to meet
>> > > our arbitrary criteria.
>> >
>> > That sort of thinking just seems so Borg to me. It's another way of
>> > saying that a software product only has value if its hosted by the
>> > ASF.
>> >
>> > If a subproject, or even a project, is down to one or two committers,
>> > and those committers can't find a third, and don't want to apply to
>> > the Commons or declare the product dormant, then setting up shop on
>> > GoogleCode is an excellent alternative. I've done the same myself, and
>> > it's not the least bit painful. In many ways, it's joyful.
>>
>> Which Apache projects have you moved to GoogleCode and found it a
>> joyful experience? ie) I presume you mean starting a project there
>> rather than moving a community from the ASF.
>>
>
> I suspect you are missing the point that *I* at least think Ted is
> making ... doing open source outside of Apache is fun, if you like
> doing open source. Doing open source inside Apache is a pain ... even
> if you like doing open source, and even if you are an insider and know
> all the loopholes.
>
>> My distaste for driving people to an open source repository is not
>> because of the repositories, but because our rules have driven them
>> out.
>>
>> > It might even be healthy if more ASF committers were involved with
>> > other hosts. The ASF may be a cult, but it should not also be a fetish
>> > :)
>>
>> Other communities, not 'host's. ie) You won't learn much from
>> code.google, java.net or sf.net other than whether you love or hate
>> the infrastructure. I bet a lot of us are involved with other
>> communities.
>>
>
> You're right that it's more community oriented than host oriented
> (because it is about the process, not the technology). You are wrong
> if you believe that "the Apache Way" (if there is such a singular
> thing, which I would dispute based on seven years of evidence to the
> contrary) makes things easier rather than harder. Yes, there are some
> benefits of the "Apache" brand, but it is an open question whether
> they are worth the costs.
>
> For myself, I have lots of ideas to do future open source projects,
> and (at the moment) zero plans to do them here at Apache. The
> emotional and procedural and cultural costs are too high to compensate
> for the branding benefits.
>
>> Hen
>
> Craig
>
> ------------------------------------------------------------ ---------
> To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: general-help@jakarta.apache.org


--
Buni Meldware Communication Suite
http://buni.org
Multi-platform and extensible Email,
Calendaring (including freebusy),
Rich Webmail, Web-calendaring, ease
of installation/administration.

Re: [PROPOSAL] The future of Jakarta

This is amazing. I agree with Craig on something almost completely.

Craig McClanahan wrote:
> On 5/30/07, Henri Yandell wrote:
>> On 5/30/07, Ted Husted wrote:
>> > On 5/26/07, Henri Yandell wrote:
>> > > Ack in terms of driving a community away because it is unable to meet
>> > > our arbitrary criteria.
>> >
>> > That sort of thinking just seems so Borg to me. It's another way of
>> > saying that a software product only has value if its hosted by the
>> > ASF.
>> >
>> > If a subproject, or even a project, is down to one or two committers,
>> > and those committers can't find a third, and don't want to apply to
>> > the Commons or declare the product dormant, then setting up shop on
>> > GoogleCode is an excellent alternative. I've done the same myself, and
>> > it's not the least bit painful. In many ways, it's joyful.
>>
>> Which Apache projects have you moved to GoogleCode and found it a
>> joyful experience? ie) I presume you mean starting a project there
>> rather than moving a community from the ASF.
>>
>
> I suspect you are missing the point that *I* at least think Ted is
> making ... doing open source outside of Apache is fun, if you like
> doing open source. Doing open source inside Apache is a pain ... even
> if you like doing open source, and even if you are an insider and know
> all the loopholes.
>
>> My distaste for driving people to an open source repository is not
>> because of the repositories, but because our rules have driven them
>> out.
>>
>> > It might even be healthy if more ASF committers were involved with
>> > other hosts. The ASF may be a cult, but it should not also be a fetish
>> > :)
>>
>> Other communities, not 'host's. ie) You won't learn much from
>> code.google, java.net or sf.net other than whether you love or hate
>> the infrastructure. I bet a lot of us are involved with other
>> communities.
>>
>
> You're right that it's more community oriented than host oriented
> (because it is about the process, not the technology). You are wrong
> if you believe that "the Apache Way" (if there is such a singular
> thing, which I would dispute based on seven years of evidence to the
> contrary) makes things easier rather than harder. Yes, there are some
> benefits of the "Apache" brand, but it is an open question whether
> they are worth the costs.
>
> For myself, I have lots of ideas to do future open source projects,
> and (at the moment) zero plans to do them here at Apache. The
> emotional and procedural and cultural costs are too high to compensate
> for the branding benefits.
>
>> Hen
>
> Craig
>
> ------------------------------------------------------------ ---------
> To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: general-help@jakarta.apache.org