commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Martin Cooper" <>
Subject Re: Blogging on Commons
Date Sun, 09 Nov 2008 05:01:27 GMT
On Sat, Nov 8, 2008 at 12:46 PM, Jochen Wiedmann

> On Sat, Nov 8, 2008 at 7:51 PM, Martin Cooper <> 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

> --
> 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,
>       My guess: Nokia E50)
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

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