commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Martin Cooper" <mart...@apache.org>
Subject Re: Blogging on Commons
Date Sat, 08 Nov 2008 18:51:07 GMT
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 <flamefew@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
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message