[development] An alternative to common thinking in 5-> 6 migration
mpartap at gmx.net
Fri Mar 13 05:35:30 UTC 2009
(uuhm sorry about the former reply that ehh wasn't ready yet.)
> Let me point out again that this is open source and not a corporate
> environment, and hence the difference. Basically everything we assumed
> about how corporate shops work does not work at all, or not as well in
> open source.
Point true 80%. There are comparable situations, in which similar
methods can successfully be applied.
> When I asked him how does this apply to open source, and the success it
> had without this lengthy centralized planning. He did not have an answer.
> Once you have hundreds and thousands of contributors who never met each
> other, spread across the globe, each scratching their own (or their
> client/employer's) itch, we have a new paradigm (yeah, another
> buzzword). You have organized chaos.
This it in fact very true. This is the great method of success for
this kind of software. However as the project grows, you get into a
situation where the chaos gets too big of a mess. Additionally, one
thing an evolutionary software development process does achieve is
building experience. Competition also does help in that phase. BUT
this all takes part with D6 contrib - and is also creating problems.
These can be solved by applying methods which are meant to filter by
quality standards - but ONLY because we have such a huge stash of
already working code to pick from! In the whole D6 cycle, i'd never
have proposed to restrict code committing, just because of all the
reasons people have brought up in this discussion!
But because we DO have all that GPLed code available, and a great lot
of skilled coders, we could now shift focus for D7 from creating
modules for each use case to _building a structure that can handle
each use case_. We can do so by selecting from all the great code
there already is - but the process of careful structural design and
_selecting good code_ is a procedure that will filter out all the
(small) issues which have come up in the past such as code
duplication, disregard of coding standards and low quality. If we want
D7 to really rock as hard as possible, we surely want to minimize
these problems. That is the reason why i still believe that overlaying
a new method onto the drupal project and community as it stands now is
a viable way to go. This would not have been the case at any point in
time before - simply because we NEEDED the drastic level of
competition and free form creativity!
> So, jump in and "Do". Write about it 6 and 12 months from now and see if
> you have changed your mind, and what you learned.
Ok well even though i might seem naive and immature at times, i
actually have 'done', furthermore always reflect and adapt to reality
as it is. I have been with this great project for almost a year,
although with low visibility and only few code inside some of core and
several modules. But i do have a good understanding of how open source
projects work, really (duh i use hundreds of them, and contributed to
a handful - still small stuff though, started programming only two
years ago.. but getting better ;). Sometimes it really *is* all about
the color of the damn bike shed ^ ^
"Obstacles are those frightful things you see when you take
your eyes off your goal." -- Henry Ford (1863-1947)
Change the world! Vote: http://hfopi.org/vote-future
More information about the development