The development of Geomorph

The philosophy
The contribution opportunities

The philosophy

As said in the introduction, Geomorph is an answer to my own landscapes creation requirements. It is designed progressively, when ideas of new landscapes ask for new tools.

Most landscapes ideas are derivated from memories or personal experiences with some aesthetic feeling. Occasionally they come from readings. For instance, research articles about the natural process of dunes growth brought me to create tools for generating dunes and ripples in version 0.3 of Geomorph. Desert scenes were imagined and created for tuning these tools, and these tools were tuned for creating these scenes...

For those who know the Eric S. Raymond Essay, The Cathedral and the Bazaar, Geomorph is not a cathedral, nor a bazaar. It's both! I have a plan, quite well defined, but also quite loose (not formally documented), which evolves from trials and errors, discoveries, and feedback of users.

Through this half-planned, half-opportunistic roadmap, the development of Geomorph follows some principles, which can be summed up in this way:

Because of these principles, Geomorph's releases are relatively scarce. I'm not so sure if the "Release early, release often" rule is always a good thing. I test new tools a lot, first for bugs, then because I want to be sure that the intended tasks can be done with them with some comfort. Users won't keep using a program which crashes and is awkward.

I must also say that the Geomorph development and documentation are mainly a hobby, between my family and a full-time job unrelated to the creation of virtual landscapes.

Testing and documenting a program creates some kind of dialog between the usage model and the program model. Each one improves from the improvement of the other. Using the tools shows their limitations, I improve them, I discover new way of using them, I improve the usage model, which feeds the software model (the tools) and so on. This is a feedback loop, a back and forth movement between a deductive line of thought (from the software model towards the usage model) and an inductive one (from the effective usage towards the software model). Said differently, by using the language of data modellers, this is a back and forth play between a "top-down" approach and a "bottom-up" approach. This is also the way scientific theories are built up, and I don't think that software can be built up differently. This is the way human beings learn.

Software development is not only an engineering undertaking, nor it is an act of pure creativity or free-speech. A program is a built artifact, and because of this, it shows some formal properties which are of interest to the mathematician, the engineer, the logician. But it is also a text which communicates meanings and intellectual processes (a program can be read and understood by human beings, even when it is too buggy to run), and because of this it is an object of creativity and free-speech, which is of interest for the philosopher, the linguist, the psychologist, and maybe some artists. Finally, and particularly, when it works, a program is a system, a whole showing properties which cannot be explained by looking at its parts. One of these properties is the completeness (this word is not necessarily used in its formal meaning here), which we feel when looking at something which seems at the same time "complex", "well-balanced", and "simple". This property can be shared by almost all products of the human mind, including the works of art and the scientific theories. In my opinion, the ability which allows us to detect this property is of the aesthetic kind.

The contribution opportunities

For now, I design and program Geomorph alone. I'm also the main tester.

I got constructive comments from some users, which helped me to evolve the product.

In the same way, all your comments are welcome: what is the main use of the software for you, what tasks are difficult to perform with it, what do you suggest, and so on.

I also got appreciated contributions from two German users, Tim SchŘrmann, who translated the 0.22 version, and Simon Donike, who continued the work for the 0.3 version. Simon also tested a lot the 0.3 version before its release and gave feedback about the html documentation.

I don't have a well-defined development model. I don't have "jobs" to propose for now. However, I am glad to accept offers like those of Tim and Simon. The main prerequisite: the Geomorph development should keep on being fun. For that it must respect some conditions:
As far as I am concerned, I don't want to become a manager in the traditional meaning of the word. It would become a "work" and I want to  keep this for my career, not for my hobbies.

In this framework, some contributions are easier to integrate with the project than others. Here are some possibilities, in an increasing order of difficulty:
  1. The translations are among the easiest contributions. The prerequisites are that you understand the source language, that you understand very well how to use Geomorph, and that you master the target language in its written form. The source languages would be English or French for the foreseeable future. For now I prefer to continue to publish in both languages, because sometimes, I write first in English - even though my English is not up to the level of my French, being my second language. The translation of the software shouldn't be mixed up with the translation of the web site. Translating the software amounts to translating 400 to 500 words and phrases used in screen dialogs. These strings are saved in a text file with the .po extension. The translator should be able to understand these strings in their context, this is why he or she should be a good user of Geomorph. The translation of the web site is a more risky undertaking. This is a lot of work, concerning documents which evolve frequently.
  2. Reviewers would be welcomed contributors. The web site and the screen dialogs would benefit from external proof-reading, for clarity, quality, syntax, and so on. I would particularily appreciate the contribution of English-speaking reviewers. 
  3. Testing prereleases under different Linux distributions and setups would also be a nice contribution. Compiling, installing and using are the three main points to test. The prerequisite are to be resourceful, to persevere, and to be able to describe the problems encountered. To perform compiling tests also requires some technical knowledge.
  4. Designing textures and eventually predefined Povray scenes (which I call somewhere "scene templates") are another contribution possibility. The prerequisites are the knowledge of Povray and an eye for natural phenomenons, in order to simulate natural textures with realism.
  5. The improvement of install scripts and the creation of packages for specific distributions (.rpm, .deb...) is another matter of contribution. I am not comfortable with this part of the development process. Knowledgeable contributors would be appreciated. Among the prerequisites, there is the knowledge of scripting languages (bash, rpms "specs", and so on), of the target distributions and of the compilation process.
  6. The interface with other renderers. Geomorph works with Povray  because this was the renderer I knew when I started the project. The current Povray version (3,6) in not free in the sense of the GPL. Free renderers like Aqsis or YafRay could be used in the future. One could contribute an interface and predefined scenes or templates with these renderers, or others unknown to me. However, a feasibilty and opportunity evaluation is required for each rendered. When the renderer does not accept height fields as images, but only meshes, using it would imply a conversion at each run and would be awkward.
  7. The development (designing and programming) is probably the most difficult contribution, for the contributor and for me. Here I would insist more on autonomy and knowledge. About the programming part, some prerequisites are the knowledge of C and of the GTK library. The programmer should also feel comfortable with my programming style and the code structure, even if he / she doesn't totally endorse them. A few words about this: I was cautious about the data and programs structures. However, having worked outside of software development for the last fifteen years or so, I probably developped an uncommon style, unrelated to any specific developpers community. I don't know, either, all the relevant standards (I found the GNU ones too long to read...). However I would be very glad to have my code reread and criticized. Anyway, if you want to explore this possibility of contribution, the first step if to read the code! About the design of the software, there are more than one aspects: think about the internal structures, the interface, the tools, but also the science or craftmanship behind the algorithms. Who knows, maybe some of you are geomorphology experts and would like to feed me, if we can find a common language?
Other contribution opportunities can be foreseen in the future, depending on how people will receive the next versions of Geomorph and the development path it will follow. There could be "jobs", for instance, for moderating and managing a forum, or for managing an online database which could contain Povray textures or objects provided by Geomorph users.

Written in September 2005

Contact:    Patrice St-Gelais Logo