A really useful package must be easy to obtain, to compile, to use and to change, giving users and developers as much control as possible. This means:

1) Designing an elegant and flexible architecture for the whole package, including hidden resources as the memory and graphic engines, and visible mechanisms as the graphical user interface. This is particularly important in a package that aims to be used in scientific research, where the required functionality is quickly changing and the capacity to adapt to new demands is critical.

2) Writing simple, well documented code. We put great emphasis in the quality of the code that we write, because: i) it is open source, so everyone can judge our work (thanks for the fish!); ii) writing beatiful code is an important incentive to continue the project; iii) simple, clean, code is easier to understand and maintain, thus atracting more developers to the project and increasing its probabilities of long term sucess.

3) Using standards and reducing code dependencies as much as possible. We use only ANSI C code in GAMGI, so gcc could be replaced by any other C compiler. We don't use Mesa-specific functions, so Mesa could be replaced by any other OpenGL implementation. We use Gtk only to write GUI-specific code, so Gtk could be replaced, without much pain, by any other X toolkit library. We plan to use only the most common Python/Perl functions in filters to convert file formats, this way making it easier for non-Python/Perl mongers to understand and change the scripts.

4) Reducing as much as possible the number of libraries the package depends on, particularly those more difficult to install, less maintained and more susceptible to changes. This helps to reduce the wall between users and programs, encouraging them to compile and modify the source code, instead of just using black-box executables. Writing a few hundred lines of code to avoid depending of a library is not reinventing the wheel, but to increase freedom for users and developers.

5) Building the package in a way as simple and transparent as possible. Using config, make, make install is simple, when it works, but makes it completely impossible to understand what is actually occurring. The GAMGI makefiles are designed to be powerfull (permiting for example to compile several executables at the same time, in different directories, with different functionality) yet small and transparent to the user, making it simple to understand the logic and mechanisms used by gcc and make to build GAMGI.

6) writing insightfull documentation for both users and developers, not just explaining how things work, but also why they work that way. The first and most important line of defense to have a user-friendly package is to design it well, but in complex, comprehensive pachages, that is usually not enough, we need good manuals, where information is clear and can be found quickly. Before being software developers, we are software users, so we really understand the frustration that most users feel when they use software today, as usually manuals either don't exist, are useless or are considered as non-essential products, that users are invited to get and pay separately. We are commited to provide good documentation not just for users that want only to know how to do their job, but also to developers, who need to understand how GAMGI works, before they can change or improve its functionality.

Above all, we believe that for users and developers alike, the ultimate goal is technological control, and the key to achieve it is simplicity.