cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From dima <>
Subject Re: [IT] C2 Complexity Syndrome
Date Sat, 28 Oct 2000 14:36:10 GMT

 Can't fail to agree more.

 Not to claim anything at all, but it's exactly this "mess" that makes it
exciting to work with projects ala Cocoon, well and Open Source in
general. To an extend it's not the final peice (especially that the very
definition of a "final peice" is somewhat blured, good software should
ALWAYS be developed, hence no "final peice" as such) that is interesting
to me, it's the process.
 Why? Well, among other things I get to learn a lot. Surprisingly even to
myself, I tend to find that it's not always the toughest software (even
open source) that is the best to learn from for a great variety of
 Obviously, it's probably all about internal balance in the end of the
day. I guess no one wants to deal with something that lacks the very
basics of structure, goal and semantic meaning in it. At the same time, if
a peice is already rock solid, what's the point in working with it in the 
first place?


On Sat, 28 Oct 2000, Stefano Mazzocchi wrote:

> Robin Green wrote:
> > 
> > Stefano Mazzocchi <> wrote:
> > >Almost any IT book publisher wants me to write a book on Cocoon,
> > >wouldn't that help?
> > 
> > I'd like to be involved in writing such a book (how I'd fit it in to my
> > schedule I don't know, but...)!
> Ok.
> > >Here I totally agree and I've bugged by some contributions on this
> > >project: submitting "blackboxware" doesn't create communities. Dumping
> > >50 classes in a day and disappearing for 2 months is not the same thing
> > >as taking two months to build 50 classes and leaving the community with
> > >50 days with nothing the works.
> > >
> > >The first kills communities, the second enlarge them and make them
> > >healthier.
> > 
> > I don't understand the first paragraph. "Nothing the works"?
> Sorry, late night after spending 7 hours wasting time at Heathrow... I
> rephrase:
> I define "blackboxware" some complex piece of code that is developped
> inhouse and committed when finished.
> The hardest and best the code is, the more harm it creates to the
> community; this is because people will rather use the software rather
> than extend it. Normally, if more than one blackboxware submission is
> donated, the community will ask for a complete refactoring. (see
> Xerces2)
> It's exactly like thermodynamics, where a infinite number of small
> reversible steps is more efficient than a small number of big but
> not-reversible steps.
> The good old Software Engineering practices they teach you in college
> are bullshit: making architecture decisions without continous
> reversibility is expensive because design constraints change too much.
> Those who want to apply hardware engineering practices miserably fail.
> Open source is here to prove that such a "messy" way to do code is
> actually the only one that works and scales.
> This thesis is considered revolutionary by some italian college
> professors I met and they are trying to create an experiment to see if
> this is really the case (or do a careful analysis on open source
> dynamics compared to closed source ones).
> Anyway, it's an design pattern: "good ideas and bad code build
> communities, the other three combinations do not". This is extremely
> hard to understand, it's probably the most counter-intuitive thing about
> open source dynamics.
> -- 
> Stefano Mazzocchi      One must still have chaos in oneself to be
>                           able to give birth to a dancing star.
> <>                             Friedrich Nietzsche
> --------------------------------------------------------------------

View raw message