Hi Matti, Matti Karnaattu wrote on Thu, Sep 11, 2014 at 08:57:30PM +0300:
> And if I understand correctly, priorities goes like this: > simplicity > licensing purity > correctness > completeness Most definitely not. That's more than just a bit misleading. None of these can be put into an unambiguous linear ordering. To be of any use *qualitative* statements are required - and if accompagnied by a clarifying qualitative statement, maybe even the "is more important than" symbol is semi-acceptable: * fully free license > everything else New code will not be added to the tree unless fully free, whatever other qualities it may have, full stop. However, if the system as a whole critically depends on specific GPL code that already is in the tree and no way has yet been found to replace it, it will remain for now (example: binutils). * correctness > completeness Usually, bugs should be fixed before adding features. However, it does occasionally happen that specific features are so urgently needed that implementing them takes precendence over fixing some non-critical bugs. Also, when talking about standards, the very fact that a feature is missing can be a bug. * correctness > simplicity Fixing bugs is more urgent than refactoring for simplicity. However, keeping and making interfaces and code simple is very important, too, because useless complexity almost always causes bugs and harms usability. * completeness > simplicity If a feature is really useful and much needed, it should be added even if it entails some additional complexity: In this case, the complexity is required by the task to be solved. However, we rarely add non-standard features to standard (e.g. POSIX) utilities because standardization is quite important. Also, we don't add features that are of little usefulness. Even though simplicity seems to figure *last* in my ordering, it is still a highly important goal (and a personal favourite). And yes, that is one of the things making OpenBSD special. Most other projects seem to assign no value whatsoever to simplicity and sacrificy it to almost anything, including rank growth and lazyness. We make sure we reach our goals (in that sense, freedom, correctness, and completeness still take precendence), but only accept as much complexity as required by the goals, not more. Note that some critical project goals are missing from your list, most notably * usability * standard-conformance * security * portability Please don't try to rank these. It won't work. Most are qualitatively, essentially different, incommensurable. Many have intricate inter-dependencies, like "correctness is almost impossible without simplicity", "security is impossible without correctness", "usablity is unavoidably low without simplicity", "correctness is almost pointless without usability" and so on. We only call it success when we reach a high level of *all* of these. Yours, Ingo
