Complete.Org: Mailing Lists: Archives: freeciv-dev: December 2001:
[Freeciv-Dev] Re: Change and Freeciv [Was: Documentation, Usability and
Home

[Freeciv-Dev] Re: Change and Freeciv [Was: Documentation, Usability and

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: "Ross W. Wetmore" <rwetmore@xxxxxxxxxxxx>
Cc: Freeciv developers <freeciv-dev@xxxxxxxxxxx>
Subject: [Freeciv-Dev] Re: Change and Freeciv [Was: Documentation, Usability and Development]
From: Reinier Post <rp@xxxxxxxxxx>
Date: Sun, 2 Dec 2001 14:15:02 +0100

On Sat, Dec 01, 2001 at 11:54:02AM -0500, Ross W. Wetmore wrote:
> At 12:03 PM 01/11/28 -0500, Justin Moore wrote:
> >   Plus I'd like some more general feedback about the laundry list of
> >ideas I threw out in my rant (other than just Christian and Andrew).  Are
> >people very comfortable with what we have, or are there others that feel
> >we can make this much much better?
> 
> We can make it better, but not in the current environment. Your list has 
> a lot of very good ideas, but only a few of them will probably ever get
> the chance or attention to mature and bloom fully :-).
> 
> In economic terms, maintainers have a monopoly with a mature product and
> are not likely to seek to change or give up their current market power.
> They are the MicroSoft and you are a Linux upstart/startup.

This is not a fair comparison.  The inertness of Freeciv is caused by the
code base, the fact that Freeciv is a functioning product, and possibly
something in Freeciv's management structure as discussed elsewhere
(namely, the fact that the development model consciously chooses to
appoint monopolists to CVS write access).  It is not a question of
maintainers trying to exert their power.

> In large measure the market (read the players) likes to standardize on 
> a single flavour like this and does not want change except in trivial
> feature additions that are easy to absorb.

I don't think the existing patches are more than such changes, although
in the case of the topology rewrite the code tries to do more with an eye
on future extensibility.

> In biological terms there is a dominant species or eco-system that is
> basically stifling any new system from being established to threaten it.

When an organism is performing well (it is 'fit'), only small evolutionary
changes to it are unlikely to occur.  A drive to serious changes occurs
when you play it in a new and unfriendly environment, where it has to do
a lot of adaptation.  As long as a variant directly tries to compete with
the dominant variant, it is not in such a situation - you have to break
away and settle in a new niche.  If it becomes reasonably successful
it may compete for the same resources (in the case of software: users,
developers, libraries etc.) but you don't have to compete in the same
niche if you find a different one in which you can thrive.  E.g. a Java
Freeciv can draw on Java resources.

> A reset like dinosaur extinction, i.e. start of Freeciv 2.0 (which will
> require a year or so of dedicated development in peace in a protected 
> niche) may be required to restart diversity in the evolutionary process.

Dinosaurs don't have to die before mammals develop - the order of mammals
was in fact well developed before the dinosaurs died out, they just didn't
dominate, but body size and population count (compare market dominance
and user base) are minor variables, they can rapidly change.

> If you really like opportunity for diversity and change, then get behind
> the next Freeciv development spinoff that bases itself on an Application 
> Framework approach where 90% of the code is generic modular template,
> and variants like FreecivAC, TeamFreeciv or Freeciv III are customizable
> data packages, or managed by a small number of loadable modules. Also
> look for something in a higher level language than C where this sort of
> development is aided by the language/tools.

Many extensions imply the addition of new code to implement new behaviour
and it isn't clear whether a code/module interface can be defined in
terms of which the addition of such code can typically be implemented.

> But besides a revolutionary turnover, another way is to seed the dominant 
> species with a few evolutionary pathogens and attempt to isolate the 
> mutants in a number of carefully controlled enclaves until it is clear 
> that one is becoming the next evolutionary dominant species.  The
> advantage of this from the Freeciv maintainer perspective is that during 
> the mutation process, there may still be opportunity for crossbreeding
> and hence the dominant species may be able to selectively mutate itself
> into the next evolutionary phase and survive. But this sort of 
> enlightened attitude to change is very rare :-).

The problem is that it is hard - regardless of attitude.
 
> Also realize that mutants are often sterile. The general trend to stick
> with the current norm is not a *bad* species strategy. Mutants really
> need to work harder to prove themselves worthy of general survival.

Mutants don't need to do anything, but mutations need to spread through
the population.  E.g. the Teamciv mutations (patches) have made it into
Teamciv, but some of them have also made it into the Freeciv CVS.
A 'sterile' mutant is a patch that doesn't create a viable Freeciv.
It has to result in a working and portable piece of code, and in order
to be accepted into CVS it has to pass the moderation procedure.

Revolution is not a species strategy, but rather, a case of different
species converging in properties and competing within the same niche.
(Convergent evolution is fairly common.)  E.g. xconq, Openciv or
Objectciv (which doesn't yet exist) could compete with Freeciv.

-- 
Reinier


[Prev in Thread] Current Thread [Next in Thread]