[development] An alternative to common thinking in 5-> 6 migration

[Marcel Partap]

(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 ^ ^
regards marcel.

-- 
  "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