Hyperbola was, is and will be always oriented on long-term support resulting in a most stable system. For this goal (please refer on the packaging guidelines also) we explicit do not want to package always the newest releases of free, libre software-projects.

It is a common misconception that “newest release” should also mean “most stable” or “better system”. So if you think to complain that we just use from your current point of view quite too old packages, dependencies and / or applications, take our point also into your argumentation:

• We do not have interest in the “freshest software” we want working software resulting in a working system. Therefore we test also our packages at any time possible with care. And when something is working without errors and risks for security we see no reasoning to upgrade.
• We do not have interest in “newer is better” accepting also breaking dependencies. Broken packages, applications and libraries are in no situation acceptable for us.
• We want to motivate every user of Hyperbola to make usage of the testing-branch as Hyperbola is a community-work. So just don't compare Hyperbola only with others awaiting someone will solve it for you: If you miss something, try it yourself building, make proposals and share your insights. Hyperbola is not meant as system delivering on behalf of everyone demanding passive.
• We want a working, stable operating-system. Most designed for minimalism and oriented on the Unix philosophy, working always on democratic principles and inclusion for a colorful way of usage.
• We decline unstable software not releasing any stable sources and therefore we also decline to include more packages just for having them. All packages need maintenance afterwards and just to implement something half-way without a safe future working is never acceptable for us, may it be a service, driver, interface, library or any kind of application.

Most important we also have no interest in always stating what we “dislike” instead of doing what we really like: This is community-oriented, free and libre software itself. We want to build, offer and use an operating-system dedicated to user-freedom. Sure, we also criticize direct or indirect development in general and detail, but we do not want to end in cynicism and hatred. With this repeating also fallacies and copy them, instead of doing a complete different paradigm.

Hyperbola follows therefore three simple but clear points:

• KISS: The shortform for Keep It Simple and Stupid means that all parts in Hyperbola's repositories and software is oriented on minimalism and strict reduced dependencies.
• DIY: The shortform for Do It Yourself means that Hyperbola has no interest to deliver and distribute all favorite packages. If users want some part software, they can surely port and package it on their own, sharing also the result for the community and get more feedback for improvals.
• DRY: The shortform for Don't Repeat Yourself means that we avoid maintenance many redundant dependencies within our system itself. This principle is a best practice in software development that recommends software engineers to do something once, and only once.

Hyperbola is oriented to motivate its users to be also their own developers and to understand every aspect of their installed system. With this thought we also do not motivate users to await full-time support but to work active with solving issues when found. So we are not oriented on having someone solving issues for everyone else, but everyone is working with everyone else to solve issues.

Yes, all the work is done from volunteers and we are not able to pay anyone for support done. But we think also that this is of a greater interest: Having a free and libre system working always onwards the interest of its user, not for someone else. We think that people should be always in command and decision what their installed software is doing, transparent and open to see. And this is a goal being worthwhile, so also for every volunteer giving time and helping hands. This is for us and for you meant also as common and individual interest at the same time. This means also that it should never come to a point where an individual volunteering person is under so much pressure that this person is going to break down. We do not tolerate demands and questions endless from people demanding attention for their personal issues. We await that all parts of the community and within the team also have a generic understatement about “working together”. If this understatement is comparable to pure exploitation we will react immediately as we have no understatement to tolerate mistreatment of individuals or whole groups.

Yes, guidance is always an important concept for us. But this only works out positive when both sides are really engaged. So for sure we want to guide, support and offer mentorship. But when we see that the person awaits full-time support, meaning to get only said everything and repeat without learning and questioning, this concept is breaking immediately. At that point we stop the mentorship also and won't go on with it in the current case.

We think that it is not too much to bother and experiment individual with the own system, developing, changing and surely also experiencing problems. If there is no interest to do exactly this, there is also no real interest within Hyperbola as a system from our point of view.

We reject any binary-only packaging. That means we will never accept packages offered only in binary form or based on binary releases done. Hyperbola was, is and will always be a source-based operating-system.

We do not want to make a difference between “users” and “developers”, especially not harsh cutouts in any way. Every “user” can also be a “developer” at any point, supporting others with insights and information. Sure, if you just want to “use” Hyperbola as your operating-system this is your choice made. But demanding from anyone else that to grant support does not work out. If we recognize that individuals are not giving more back and demand endless support, we will also react in a comparable way: Noting that we do no longer grant support with answering especially when questions are clearly to be solved with reading throughout the wiki-articles. That is ignorance for protection as Hyperbola is living from its community-effort, people coming together to build something and help each other. Mistreating this is in our perspective a clear violation towards kindness and respect.

At the point Hyperbola was installed it is and will be your own system and you are responsible for running it, not anyone else. The software here included is granted under clear free, libre licensing, so you are the same way taken to acknowledge this. Awaiting something you may get from non-free but also harsh paid software is not a way forward. This software was and is done under complete different modalities. Free, libre software is working from the altruistic perspective: Someone is building something others may find good and support with time and own money. The same way forward Hyperbola is to be seen. If you like the system and project, you can always support it with your time, effort and money.

If all those points are not working for you, Hyperbola is not the system you should take into perspective for usage. We wish you therefore success to find a better suiting system-base.

Hyperbola is an independent system, no fork from others. Therefore we also kindly ask not to compare Hyperbola with others in perspectives on offered software for example. Searching for problems and issues is a complete different point, but likewise the comparisons of other projects is most time complicated or not possible the same points also work for Hyperbola.

If you want to ask for help or want to make a stable oriented system better, please stop comparisons without giving a helping hand and work with us together. Also in regards of the documentation! We hope to motivate people bringing missed applications, libraries and more as ports to Hyperbola. Our operating-system and system-distribution can only be drawn together, so we mean exactly this wording. And let us test your packaging and ports to make an even better system!

Remember that this is meant as technical emancipation. So if you have barriers before you, speak up open and let's solve them.