[PD] [ot] managing distributed development

marius schebella marius.schebella at gmail.com
Thu Aug 21 05:28:27 CEST 2008

I think methods of development (and evolution) have not changed during 
the last 4 billion years. how we view them and think about them has 
changed. the question for me is, why is it so much more important today 
to point out that development is never done by one single individuum but 
is a process that includes a lot of people adding and evaluating 
thousands of tiny and comprehensive steps?
to be honest, I think that we (the first world colonialists) have a 
growing fear that we will not survive on this planet without the "help" 
of the rest of the world. uptight as we are, we are now trying to 
"allow" everyone to take part in development, whereas in reality we are 
trying to make everyone responsible for the problems of the world.
but then, in practice it *is* the individual effort and progress that 
sums up development. and it's individuums who take responsibility.
regarding Pd, managing resources could make things more 
efficient/faster/target oriented. and competition could also speed 
things up. but it could also lead to totally useless and prestigious 
attempts like me wanting to walk on the moon!

Thomas Grill wrote:
> Hi all,
> while i'm in Boston i just had dinner with a well known researcher in
> fields of user/distributed innovation and communities.
> One of the topics of conversation was whether it would be possible to
> design management systems for distributed development (like sourceforge)
> in a way that _all_ management tasks are taken away from the
> responsibility of individual persons but rather handled in a
> quasi-automatic (community-governed by polls etc.) manner.
>>From my experience with open source development i was very sceptic but
> haven't yet really come up with a _principal_ reason why this would be
> impossible. My arguments have been more on the side of actual feasibility
> because of the development costs of such a management tool to deal with
> every conceivable subtlety and dependency in the process of development
> and packaging.
>>From a theoretical viewpoint it would though be interesting if there are
> more principal reasons why this could be impossible.
> Is the fact that the development of the tool can never come to an end such
> a principal reason?
> Any other thoughts?
> thanks and all the best, gr~~~
> _______________________________________________
> Pd-list at iem.at mailing list
> UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list

More information about the Pd-list mailing list