Blogging on Commons

[Henri Yandell <fl...@gmail.com>]

Apologies for writing this as a blog rather than an email - it felt
more natural and will pull in other opinions:

http://blog.generationjava.com/roller/bayard/entry/the-open-and-federated-commons

Hen

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org

Re: Blogging on Commons

[Christian Grobmeier <gr...@gmail.com>]

On Mon, Nov 10, 2008 at 8:51 AM, Viraj Turakhia <vi...@gmail.com>wrote:

> If I have read it right, I do agree with the point that we need to give
> committers access to people more freely.
>

Definitly.Primetime developing for Commons is no fun. It's a bit frustrating.
Maybe there should be some kind of "mentoring" at commons. Means, a new
developer who proved himself with some patches or interest gets committer
access for some kind of propation time. In that time a commiter "mentors"
that guy and takes a look at the sources.

Chris.

Re: Blogging on Commons

[Viraj Turakhia <vi...@gmail.com>]

If I have read it right, I do agree with the point that we need to give
committers access to people more freely.
Suggested solution of having a separate development branch sounds good to me
(don't know how feasible it is).


-v

On Mon, Nov 10, 2008 at 10:38 AM, Martin Cooper <ma...@apache.org> wrote:

> On Sun, Nov 9, 2008 at 8:06 AM, Luc Maisonobe <Lu...@free.fr>
> wrote:
>
> > I would strongly protest against such a move.
>
>
> I wasn't proposing such a move, merely speculating.
>
>
> > Commons are used outside
> > of the ASF and are successful there. I even think [math] is used almost
> > only outside of ASF and not internally ... Commons appear also as low
> > level libraries for general use and this should not be stopped.
> >
> > I have seen many projects that depend on a huge number of libraries. For
> > such projects, a reliable set of reusable components with consistent
> > look and feel is a sure gain.
> >
> > Low level components are important and from my experience often need
> > specific development rules, very strict ones. The reason for that is
> > that you can never make any assumptions on how a low level component
> > will be called/integrated/reused from a random high level complete
> > application.
> >
> > I see the views expressed in both the original post and the previous
> > message as if high level applications were the only important thing and
> > low level components were second class "toys" to share but not to care
> > too much about. Is this really what you meant or did I misunderstood
> > your point ?
>
>
> I believe you misunderstood. I know that I did not mean to imply that, and
> I'm certain that Hen didn't either. His uses of the word "toys" are a play
> on an English idiom about "taking ones toys and going home", and are not
> meant to imply that there's anything toy-like about Commons components. On
> the contrary, I think we're both arguing that Commons components are
> important enough that we want to find ways to encourage people to bring
> reusable code here rather than simply keep it to themselves and not sharing
> it.
>
> --
> Martin Cooper
>
>
> Luc
> >
> > >
> > > No answers here, I'm afraid. Just some additional thoughts to add to
> the
> > > mix.
> > >
> > > --
> > > Martin Cooper
> > >
> > >
> > > On Fri, Nov 7, 2008 at 11:20 PM, Henri Yandell <fl...@gmail.com>
> > wrote:
> > >
> > >> Apologies for writing this as a blog rather than an email - it felt
> > >> more natural and will pull in other opinions:
> > >>
> > >>
> > >>
> >
> http://blog.generationjava.com/roller/bayard/entry/the-open-and-federated-commons
> > >>
> > >> Hen
> > >>
> > >> ---------------------------------------------------------------------
> > >> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > >> For additional commands, e-mail: dev-help@commons.apache.org
> > >>
> > >>
> > >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
> >
>



-- 
The first right of human is the right of EGO.
--
http://www.xperienceexperience.blogspot.com

Re: Blogging on Commons

[Luc Maisonobe <Lu...@free.fr>]

Martin Cooper a écrit :
> On Sun, Nov 9, 2008 at 8:06 AM, Luc Maisonobe <Lu...@free.fr> wrote:
> 
>> I would strongly protest against such a move.
> 
> 
> I wasn't proposing such a move, merely speculating.
> 
> 
>> Commons are used outside
>> of the ASF and are successful there. I even think [math] is used almost
>> only outside of ASF and not internally ... Commons appear also as low
>> level libraries for general use and this should not be stopped.
>>
>> I have seen many projects that depend on a huge number of libraries. For
>> such projects, a reliable set of reusable components with consistent
>> look and feel is a sure gain.
>>
>> Low level components are important and from my experience often need
>> specific development rules, very strict ones. The reason for that is
>> that you can never make any assumptions on how a low level component
>> will be called/integrated/reused from a random high level complete
>> application.
>>
>> I see the views expressed in both the original post and the previous
>> message as if high level applications were the only important thing and
>> low level components were second class "toys" to share but not to care
>> too much about. Is this really what you meant or did I misunderstood
>> your point ?
> 
> 
> I believe you misunderstood. I know that I did not mean to imply that, and
> I'm certain that Hen didn't either. His uses of the word "toys" are a play
> on an English idiom about "taking ones toys and going home", and are not
> meant to imply that there's anything toy-like about Commons components. On
> the contrary, I think we're both arguing that Commons components are
> important enough that we want to find ways to encourage people to bring
> reusable code here rather than simply keep it to themselves and not sharing
> it.

That's fine, then. Sorry for my lack of cultural background.

Luc

> 
> --
> Martin Cooper
> 
> 
> Luc
>>> No answers here, I'm afraid. Just some additional thoughts to add to the
>>> mix.
>>>
>>> --
>>> Martin Cooper
>>>
>>>
>>> On Fri, Nov 7, 2008 at 11:20 PM, Henri Yandell <fl...@gmail.com>
>> wrote:
>>>> Apologies for writing this as a blog rather than an email - it felt
>>>> more natural and will pull in other opinions:
>>>>
>>>>
>>>>
>> http://blog.generationjava.com/roller/bayard/entry/the-open-and-federated-commons
>>>> Hen
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>
>>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
> 



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org

Re: Blogging on Commons

[Martin Cooper <ma...@apache.org>]

On Sun, Nov 9, 2008 at 8:06 AM, Luc Maisonobe <Lu...@free.fr> wrote:

> I would strongly protest against such a move.


I wasn't proposing such a move, merely speculating.


> Commons are used outside
> of the ASF and are successful there. I even think [math] is used almost
> only outside of ASF and not internally ... Commons appear also as low
> level libraries for general use and this should not be stopped.
>
> I have seen many projects that depend on a huge number of libraries. For
> such projects, a reliable set of reusable components with consistent
> look and feel is a sure gain.
>
> Low level components are important and from my experience often need
> specific development rules, very strict ones. The reason for that is
> that you can never make any assumptions on how a low level component
> will be called/integrated/reused from a random high level complete
> application.
>
> I see the views expressed in both the original post and the previous
> message as if high level applications were the only important thing and
> low level components were second class "toys" to share but not to care
> too much about. Is this really what you meant or did I misunderstood
> your point ?


I believe you misunderstood. I know that I did not mean to imply that, and
I'm certain that Hen didn't either. His uses of the word "toys" are a play
on an English idiom about "taking ones toys and going home", and are not
meant to imply that there's anything toy-like about Commons components. On
the contrary, I think we're both arguing that Commons components are
important enough that we want to find ways to encourage people to bring
reusable code here rather than simply keep it to themselves and not sharing
it.

--
Martin Cooper


Luc
>
> >
> > No answers here, I'm afraid. Just some additional thoughts to add to the
> > mix.
> >
> > --
> > Martin Cooper
> >
> >
> > On Fri, Nov 7, 2008 at 11:20 PM, Henri Yandell <fl...@gmail.com>
> wrote:
> >
> >> Apologies for writing this as a blog rather than an email - it felt
> >> more natural and will pull in other opinions:
> >>
> >>
> >>
> http://blog.generationjava.com/roller/bayard/entry/the-open-and-federated-commons
> >>
> >> Hen
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >> For additional commands, e-mail: dev-help@commons.apache.org
> >>
> >>
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>

Re: Blogging on Commons

[Luc Maisonobe <Lu...@free.fr>]

Martin Cooper a écrit :
> Interesting post. Allow me to do some thinking out loud of my own. ;-)
> 
> IMHO, in its earlier days, Commons worked well in that quite a few projects
> did "donate" parts of their code bases to Commons, thus seeding it and
> enhancing the commonality between those projects and promoting sharing
> beyond the ASF as well. In fact, I believe that it is actually Commons'
> success that has led to some of the problems that we see today, and some of
> the problems you blogged about.
> 
> You see, we actually did two things with Commons, one of which we explicitly
> set out to do, and the other that I don't think we really thought about too
> much, at least at that time. The former is what you describe in your blog
> post - "a place for Jakarta [and later, other] projects to come together".
> Great idea, great initial execution, and I think many projects, Jakarta and
> otherwise, have benefited from that.
> 
> The second thing we did was to expose these common pieces of code as ASF
> release artifacts, and to promote them as reusable components outside of the
> ASF. This was a fairly natural thing to do. After all, if the code is
> reusable across ASF projects, then it's probably reusable across non-ASF
> projects as well. However, I think it's the extent to which we have gone
> down this path that has led to many of the problems.
> 
> For example, one of the reasons people don't want to bring things to Commons
> any more is because they have to buy in to the entire Commons enchilada.
> Consistent build systems, consistent web sites, consistent release criteria,
> and so on. This consistency is crucial when Commons is being promoted to the
> "outside world", because it allows consumers to understand what they will
> see / get from any given component. I believe it's a big part of what has
> made Commons a "brand" in and of itself, and for Commons as an
> externally-facing project, it's definitely a Good Thing (tm).
> 
> However, this is a pain in the neck for the Commons developers, and it's a
> significant hurdle for someone bringing code to Commons from some other ASF
> project. Thinking back to when Struts broke out several chunks of code
> (BeanUtils, Digester, etc.) and moved them to the nascent Commons, that was
> straightforward because each component pretty much did its own thing back
> then. Would we have done the same thing if we'd had to go through today's
> shenanigans? I don't know, but it wouldn't have been the slam dunk that it
> was.
> 
> What's the answer? I don't know. It would be kinda antisocial to "take
> Commons private" and make it "internal use only", although that might be the
> easiest way to relax the rules and make it easier for projects to "donate"
> parts of their code base. With such a model, we might even eliminate
> releases altogether and leave the onus on the consuming projects to
> determine the quality of whatever tag / revision they consume. There would
> be pressure, in some form, to release some of the pieces, and the question
> then becomes one of who would be willing to go through the extra steps to
> create a release out of an internal shared library, especially if that was
> not necessary for internal consumption.

I would strongly protest against such a move. Commons are used outside
of the ASF and are successful there. I even think [math] is used almost
only outside of ASF and not internally ... Commons appear also as low
level libraries for general use and this should not be stopped.

I have seen many projects that depend on a huge number of libraries. For
such projects, a reliable set of reusable components with consistent
look and feel is a sure gain.

Low level components are important and from my experience often need
specific development rules, very strict ones. The reason for that is
that you can never make any assumptions on how a low level component
will be called/integrated/reused from a random high level complete
application.

I see the views expressed in both the original post and the previous
message as if high level applications were the only important thing and
low level components were second class "toys" to share but not to care
too much about. Is this really what you meant or did I misunderstood
your point ?

Luc

> 
> No answers here, I'm afraid. Just some additional thoughts to add to the
> mix.
> 
> --
> Martin Cooper
> 
> 
> On Fri, Nov 7, 2008 at 11:20 PM, Henri Yandell <fl...@gmail.com> wrote:
> 
>> Apologies for writing this as a blog rather than an email - it felt
>> more natural and will pull in other opinions:
>>
>>
>> http://blog.generationjava.com/roller/bayard/entry/the-open-and-federated-commons
>>
>> Hen
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
> 



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org

Re: Blogging on Commons

[sebb <se...@gmail.com>]

On 09/11/2008, Martin Cooper <ma...@apache.org> wrote:
> On Sat, Nov 8, 2008 at 12:46 PM, Jochen Wiedmann
>  <jo...@gmail.com>wrote:
>
>
>  > On Sat, Nov 8, 2008 at 7:51 PM, Martin Cooper <ma...@apache.org> wrote:
>  >
>  > > For example, one of the reasons people don't want to bring things to
>  > Commons
>  > > any more is because they have to buy in to the entire Commons enchilada.
>  > > Consistent build systems, consistent web sites, consistent release
>  > criteria,
>  > > and so on. This consistency is crucial when Commons is being promoted to
>  > the
>  > > "outside world", because it allows consumers to understand what they will
>  > > see / get from any given component. I believe it's a big part of what has
>  > > made Commons a "brand" in and of itself, and for Commons as an
>  > > externally-facing project, it's definitely a Good Thing (tm).
>  >
>  > I don't agree with that. IMO, it's gross how much a commons
>  > subproject is influenced by others. I'd clearly prefer if the subprojects
>  > were
>  > completely driven by those who actually do the subprojects work.
>
>
>
> But that's exactly my point. If you're a (prospective) Commons developer,
>  you quite likely don't want to have to buy into the whole Commons enchilada,
>  and would likely prefer to just get on and do things your own way. However,
>  if you're someone looking to consume Commons within an enterprise (which is
>  part of what I meant by the "outside world"), that consistency across all
>  Commons components is a great benefit, because once you understand how one
>  of them works, you understand how they all work (within reason, of course).

It's also a lot easier for committers to work on multiple commons
projects if the components all do things in the same way.

And it probably helps with PMC oversight too.

>  --
>  Martin Cooper
>
>
>
>  Jochen
>  >
>  >
>  > --
>  > I have always wished for my computer to be as easy to use as my
>  > telephone; my wish has come true because I can no longer figure out
>  > how to use my telephone.
>  >
>  >    -- (Bjarne Stroustrup,
>
> > http://www.research.att.com/~bs/bs_faq.html#really-say-that<http://www.research.att.com/%7Ebs/bs_faq.html#really-say-that>
>
> >       My guess: Nokia E50)
>  >
>  > ---------------------------------------------------------------------
>  > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>  > For additional commands, e-mail: dev-help@commons.apache.org
>  >
>  >
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org

Re: Blogging on Commons

[Phil Steitz <ph...@gmail.com>]

On 11/9/08, Martin Cooper <ma...@apache.org> wrote:
> On Sat, Nov 8, 2008 at 12:46 PM, Jochen Wiedmann
> <jo...@gmail.com>wrote:
>
> > On Sat, Nov 8, 2008 at 7:51 PM, Martin Cooper <ma...@apache.org> wrote:
> >
> > > For example, one of the reasons people don't want to bring things to
> > Commons
> > > any more is because they have to buy in to the entire Commons enchilada.
> > > Consistent build systems, consistent web sites, consistent release
> > criteria,
> > > and so on. This consistency is crucial when Commons is being promoted to
> > the
> > > "outside world", because it allows consumers to understand what they will
> > > see / get from any given component. I believe it's a big part of what has
> > > made Commons a "brand" in and of itself, and for Commons as an
> > > externally-facing project, it's definitely a Good Thing (tm).
> >
> > I don't agree with that. IMO, it's gross how much a commons
> > subproject is influenced by others. I'd clearly prefer if the subprojects
> > were
> > completely driven by those who actually do the subprojects work.
>
>
> But that's exactly my point. If you're a (prospective) Commons developer,
> you quite likely don't want to have to buy into the whole Commons enchilada,
> and would likely prefer to just get on and do things your own way. However,
> if you're someone looking to consume Commons within an enterprise (which is
> part of what I meant by the "outside world"), that consistency across all
> Commons components is a great benefit, because once you understand how one
> of them works, you understand how they all work (within reason, of course).
>

Not sure I agree with either of the conclusions above - either the
statement about what users like or what causes pain for contributors.
Regarding users, while I don't have hard data to support this, I
suspect that the vast majority of commons users (inside and outside
the ASF) don't muck with the builds at all - i.e., they download jars
or have maven do it and just use the components.  For this use, it
makes no difference whether the jars were built using Ant, Maven 1,
Maven 2 or something else.  So I don't agree with the statement that
everyone using the same build structure helps users all that much.
Common look-and-feel for sites may have some value, but as long as the
nav is not horrendous, I personally don't see this as a big deal.  I
don't remember users complaining about it when we had a mix of maven
and anakia-generated sites a few years back.

I also disagree with the "whole enchilada" idea as the primary cause
of pain for contributors.  The problem for new contributors is getting
builds to work at all and then for the true punishment-seekers,
navigating the release process.  The release obstacles here are as
much ASF obstacles as commmons - lots of quasi-documented requirements
about what has to be included, what to vote on, how tags need to work,
etc.  At the end of the Maven 1 period, we at least had a documented
process for building and cutting releases that made it a little easier
for people to get started and even push out releases.  My HO here is
that if we could get a really fully functional standardized way to
build and release in M2, it would actually be a lot easier for people
and there would be no reason for people to want to "do their own
thing" since the standardized way would save them boring work.  We
have gotten close to this thanks to Niall,. Dennis, Rahul and a few
others and I think things will be better when we have sorted out the
last bits.  That said, I have always maintained that do-ocracy should
trump tidiness here, so those doing the work to develop and cut
releases should be allowed to choose, as long as what we vote on ends
up meeting ASF requirements.

Phil

> --
> Martin Cooper
>
>
> Jochen
> >
> >
> > --
> > I have always wished for my computer to be as easy to use as my
> > telephone; my wish has come true because I can no longer figure out
> > how to use my telephone.
> >
> >    -- (Bjarne Stroustrup,
> > http://www.research.att.com/~bs/bs_faq.html#really-say-that<http://www.research.att.com/%7Ebs/bs_faq.html#really-say-that>
> >       My guess: Nokia E50)
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
> >
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org

Re: Blogging on Commons

[Martin Cooper <ma...@apache.org>]

On Sat, Nov 8, 2008 at 12:46 PM, Jochen Wiedmann
<jo...@gmail.com>wrote:

> On Sat, Nov 8, 2008 at 7:51 PM, Martin Cooper <ma...@apache.org> wrote:
>
> > For example, one of the reasons people don't want to bring things to
> Commons
> > any more is because they have to buy in to the entire Commons enchilada.
> > Consistent build systems, consistent web sites, consistent release
> criteria,
> > and so on. This consistency is crucial when Commons is being promoted to
> the
> > "outside world", because it allows consumers to understand what they will
> > see / get from any given component. I believe it's a big part of what has
> > made Commons a "brand" in and of itself, and for Commons as an
> > externally-facing project, it's definitely a Good Thing (tm).
>
> I don't agree with that. IMO, it's gross how much a commons
> subproject is influenced by others. I'd clearly prefer if the subprojects
> were
> completely driven by those who actually do the subprojects work.


But that's exactly my point. If you're a (prospective) Commons developer,
you quite likely don't want to have to buy into the whole Commons enchilada,
and would likely prefer to just get on and do things your own way. However,
if you're someone looking to consume Commons within an enterprise (which is
part of what I meant by the "outside world"), that consistency across all
Commons components is a great benefit, because once you understand how one
of them works, you understand how they all work (within reason, of course).

--
Martin Cooper


Jochen
>
>
> --
> I have always wished for my computer to be as easy to use as my
> telephone; my wish has come true because I can no longer figure out
> how to use my telephone.
>
>    -- (Bjarne Stroustrup,
> http://www.research.att.com/~bs/bs_faq.html#really-say-that<http://www.research.att.com/%7Ebs/bs_faq.html#really-say-that>
>       My guess: Nokia E50)
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>

Re: Blogging on Commons

[Jochen Wiedmann <jo...@gmail.com>]

On Sat, Nov 8, 2008 at 7:51 PM, Martin Cooper <ma...@apache.org> wrote:

> For example, one of the reasons people don't want to bring things to Commons
> any more is because they have to buy in to the entire Commons enchilada.
> Consistent build systems, consistent web sites, consistent release criteria,
> and so on. This consistency is crucial when Commons is being promoted to the
> "outside world", because it allows consumers to understand what they will
> see / get from any given component. I believe it's a big part of what has
> made Commons a "brand" in and of itself, and for Commons as an
> externally-facing project, it's definitely a Good Thing (tm).

I don't agree with that. IMO, it's gross how much a commons
subproject is influenced by others. I'd clearly prefer if the subprojects were
completely driven by those who actually do the subprojects work.


Jochen


-- 
I have always wished for my computer to be as easy to use as my
telephone; my wish has come true because I can no longer figure out
how to use my telephone.

    -- (Bjarne Stroustrup,
http://www.research.att.com/~bs/bs_faq.html#really-say-that
       My guess: Nokia E50)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org

Re: Blogging on Commons

[Martin Cooper <ma...@apache.org>]

Interesting post. Allow me to do some thinking out loud of my own. ;-)

IMHO, in its earlier days, Commons worked well in that quite a few projects
did "donate" parts of their code bases to Commons, thus seeding it and
enhancing the commonality between those projects and promoting sharing
beyond the ASF as well. In fact, I believe that it is actually Commons'
success that has led to some of the problems that we see today, and some of
the problems you blogged about.

You see, we actually did two things with Commons, one of which we explicitly
set out to do, and the other that I don't think we really thought about too
much, at least at that time. The former is what you describe in your blog
post - "a place for Jakarta [and later, other] projects to come together".
Great idea, great initial execution, and I think many projects, Jakarta and
otherwise, have benefited from that.

The second thing we did was to expose these common pieces of code as ASF
release artifacts, and to promote them as reusable components outside of the
ASF. This was a fairly natural thing to do. After all, if the code is
reusable across ASF projects, then it's probably reusable across non-ASF
projects as well. However, I think it's the extent to which we have gone
down this path that has led to many of the problems.

For example, one of the reasons people don't want to bring things to Commons
any more is because they have to buy in to the entire Commons enchilada.
Consistent build systems, consistent web sites, consistent release criteria,
and so on. This consistency is crucial when Commons is being promoted to the
"outside world", because it allows consumers to understand what they will
see / get from any given component. I believe it's a big part of what has
made Commons a "brand" in and of itself, and for Commons as an
externally-facing project, it's definitely a Good Thing (tm).

However, this is a pain in the neck for the Commons developers, and it's a
significant hurdle for someone bringing code to Commons from some other ASF
project. Thinking back to when Struts broke out several chunks of code
(BeanUtils, Digester, etc.) and moved them to the nascent Commons, that was
straightforward because each component pretty much did its own thing back
then. Would we have done the same thing if we'd had to go through today's
shenanigans? I don't know, but it wouldn't have been the slam dunk that it
was.

What's the answer? I don't know. It would be kinda antisocial to "take
Commons private" and make it "internal use only", although that might be the
easiest way to relax the rules and make it easier for projects to "donate"
parts of their code base. With such a model, we might even eliminate
releases altogether and leave the onus on the consuming projects to
determine the quality of whatever tag / revision they consume. There would
be pressure, in some form, to release some of the pieces, and the question
then becomes one of who would be willing to go through the extra steps to
create a release out of an internal shared library, especially if that was
not necessary for internal consumption.

No answers here, I'm afraid. Just some additional thoughts to add to the
mix.

--
Martin Cooper


On Fri, Nov 7, 2008 at 11:20 PM, Henri Yandell <fl...@gmail.com> wrote:

> Apologies for writing this as a blog rather than an email - it felt
> more natural and will pull in other opinions:
>
>
> http://blog.generationjava.com/roller/bayard/entry/the-open-and-federated-commons
>
> Hen
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>