kanidm/project_docs/DEVELOPER_PRINCIPLES.md

76 lines
3.1 KiB
Markdown
Raw Normal View History

# Developer Principles
As a piece of software that stores the identities of people, the project becomes
bound to social and political matters. The decisions we make have consequences
on many people - many who never have the chance to choose what software is used
to store their identities (think employees in a business).
This means we have a responsibility to not only be aware of our impact on our
direct users (developers, system administrators, dev ops, security and more)
but also the impact on indirect consumers - many of who are unlikely to be in
a position to contact us to ask for changes and help.
## Ethics / Rights
If you have not already, please see our documentation on [rights and ethics]
[rights and ethics]: https://github.com/kanidm/kanidm/blob/master/ethics/README.md
## Humans First
We must at all times make decisions that put humans first. We must respect
all cultures, languages, and identities and how they are represented.
This may mean we make technical choices that are difficult or more complex,
or different to "how things have always been done". But we do this to
ensure that all people can have their identities stored how they choose.
For example, any user may change their name, display name and legal name at
any time. Many applications will break as they primary key from name when
this occurs. But this is the fault of the application. Name changes must
be allowed. Our job as technical experts is to allow that to happen.
We will never put a burden on the user to correct for poor designs on
our part. For example, locking an account if it logs in from a different
country unless the user logs in before hand to indicate where they are
going. This makes the user responsible for a burden (changing the allowed login
country) when the real problem is preventing bruteforce attacks - which
can be technically solved in better ways that don't put administrative
load to humans.
## Correct and Simple
As a piece of security sensitive software we must always put correctness
first. All code must have tests. All developers must be able to run all
tests on their machine and environment of choice.
This means that the following must always work:
git clone ...
cargo test
If a test or change would require extra requirements, dependencies, or
preconfiguration, then we can no longer provide the above. Testing must
be easy and accesible, else we wont do it, and that leads to poor
software quality.
The project must be simple. Any one should be able to understand how it
works and why those decisions were made.
## Languages
The core server will (for now) always be written in Rust. This is due to
the strong type guarantees it gives, and how that can help raise the
quality of our project.
## Over-Configuration
Configuration will be allowed, but only if it does not impact the statements
above. Having configuration is good, but allowing too much (IE a scripting
engine for security rules) can give deployments the ability to violate human
first principles, which reflects badly on us.
All configuration items, must be constrained to fit within our principles
so that every kanidm deployment, will always provide a positive experience
to all people.