Re: Light Princess -- Where are those programmers?

[nlin <nlin@www.zum-thema.com>]

> I've run into to two types of problems interfacing
> with the programming side of the fence:
> 
> 1) They say "well, write me a specification
> 2) They don't want to follow my plans.
> 
> I was originally under the impression that in the open
> source world, I'd need to grant maximum creative freedom
> to the programmers in order to get interest.

Although I only have a small amount of experience in the open-source
software development process, I do have much experience with software
development in general. I have a few comments on this which hopefully
may help.

First, it is always much easier for a programmer to join a project
when some sort of working code base already exists. This has the
following advantages:

1) The architecture is solidified into a working form in the code.
   It *works*. Programmers can argue all they want, and can change
   the architecture if need be, but they at least have a starting,
   *working* base to go from. Without this, endless speculation about
   "well, wouldn't this be better?" can result.
2) Programmers don't need to understand everything in order to start
   work on some small part. Within a framework, programmers (at least,
   good, team-oriented programmers) won't feel that they have to 
   question every design decision. Decisions will have been made,
   but programmers can see that they work and can focus their energy
   on integrating additional functionality within that framework.
   "Form is liberating" is the artist's creed.
3) It raises the chances that the project will have some sort of
   "architectural integrity". If too many (possibly inexperienced)
   programmers keep on arguing about possible architectures,
   the project can become fragmented and totally out of control.

I looked at your materials on your web site. Very impressive indeed.
You seem to have a very clear idea of what you need, and with what
architecture you want to realize it.

My suggestion would be to try to find one or two good programmers whom
you feel you can trust to implement and make the inevitable additional
decisions that occur when implementing a design. Have these programmers
work closely with you for a few months implementing the core aspects
of the architecture. After doing this you too and the programmers
will get a much clearer idea of what is needed, what is NOT needed,
and how it will all fit together. Then show it to the world,
and recruit more programmers for specific tasks.

Also, do not forget that software development is inherently a dynamic
process. It is almost never possible to capture 100% of the problem
specification in a design document. The "waterfall model" of software
development (analysis, design, code, test, in that strict order)
has been widely recognized as not representative of the dynamic nature
of real software development. Therefore, it is important to
iteratively develop. This also underscores the importance of getting
a small, working core architecture up and running. With this in place,
iterative development means always adding functionality to an already
fundamentally working system, which is very encouraging. Without
iterative development, you're back to the waterfall model, where
coders try to implement every last detail from a monolithic specification
which by its very nature can never be complete and which makes later
changes to the design - which always occur in long-term real software
projects - difficult.

To summarize my thoughts:

1 - Find a programmer or two that you trust. "Self" is included.
2 - Implement a working code base for the most vital parts of the
    architecture.
3 - Iteratively flesh out the rest of the design. Recruit programmers
    for the various additional tasks.
4 - Adapt the design as the software evolves.

There are plenty of examples of open source projects which languish for
literally years because the initial founders tried to split the design
work among several uncoordinated programmers. On the other hand, there
are several very successful projects which seem to work best on the
"each programmer contributes X% of new functionality to a working core",
where X can vary from very small to very large depending on the programmer's
interest, familiarity with the problem domain, available time, etc.

I wish you the best of luck!

-Norman
nlin at linux3dgraphicsprogramming dot delete_this dot com
(parse that, spambots!)

---------------------------------------------------------------------
To unsubscribe, e-mail: linuxgames-unsubscribe@sunsite.dk
For additional commands, e-mail: linuxgames-help@sunsite.dk