19 Jan
2008
19 Jan
'08
5:01 p.m.
2008/1/19, Fred Williams <fred(a)fredwilliams.ca>ca>:
Fine a wiki for the developers and a web site
are good ideas.
Developers may come and go and getting them up to speed on the project
requires documentation and possibly training. Internal communications
is vital and every developer should be in almost constant contact with
the group to make sure everybody's on the same project and knows what is
going on. This synergistic culture is vital to such a team. It's in
everybody's interest that all the other team members understand the
project perfectly. Time spent bringing a new member up to speed is not
wasted. A developer's bulletin board is essential. Well defined
standard interfaces for code is also essential and design changes must
be tracked and approved by the core development team. Things like that
ensure a solid program.
I could get behind a project like that.
Ok, so what needs to be done to get such a project rolling?
The following is my opinion, and of course everyone is free to argue
otherwise. ;-)
When "planning" a project, I prefer to make an Assessment of the
resources that I have available first, because I somehow like to be
realistic about what really "can" be done instead of building castles
out of air and then being disappointed that it did not work out.
So, this "Project" seems to be about "Code", programming code and
such. So, while there is certainly a lot of code already out there
that can be reused, someone has to fit it together and someone has to
fill in the missing parts. So this project will involve coding. So we
need "Coders". This is how open source projects work, they need
coders. There are many people with ideas, but someone has to code it
and generally, those people are a scarce resource.
So, in planning this stuff the first thing to find out is who are the
coders, and what are they willing to do. Making big plans and then
expecting outsiders to jump in and start coding is an approach that
has proven not to work, at least as far as my experience goes.
Maybe at one point outsiders will come and start contributing, but for
that to happen, a solid core is needed, something that is of value to
contributors.
And btw. I also believe that making plans that reach too far into the
future are very, very risky, especially if one relies on volunteers.
Better make a small proposal for a well defined problem, for which a
solution is immediatly useful. Then try to get it solved as fast as
possible, before people loose interest, and then try to "infect" as
many peer groups as possible with the solution to create an
"eco-system" where the solution can sustain itself.
Then fit that part into the big picture, and move on to the next
little puzzle part.
So, I am volunteering to do stuff, who else is?
Cheers
-Richard
PS.: the discussion is distributed among the following mailinglist, so
check the archives:
https://www.bek.no/mailman/listinfo/piksel
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
--
Are you teaching the What and the How but without the Why and the When?