This is the configuration I am running on. More importantly, this should be the
configuration you run on before you do any form of static analysis on my being.
A never-ending monologue that will swallow any foreign body. Basically, this is
the A to Z to living and witch crafting as an open 🧙.

If you gaze long into an abyss, the abyss also gazes into you

Well, I don't fear the abyss.

• A developer is also a user.
• Be users/developers centric, not trends centric.
• If it's not usable, it's not secure. Version pinning yes, security through obs
  curity no, burdening users with useless actions no.
• Less configuration means less complication. Provide a very basic workflow that
  can be extended and is composable and interoperable instead of burderning user
  with unwanted features that requires unconfiguration.
• Use (wisely) principles such as the Separation Of Concerns as a mean to
  establish a clear definition of what each part of the software's job is.
  The cutting corners mindset should be antagonized. Own these hard to grasp
  concepts.
• Try not to assume that the user is using X tool or Y software (do not infer).
  Once the stack has left it up to the software, it's its job to maintain that goo
  d experience until it itself passes the torch.
• While experimenting is most certainly always a good idea,
  try not to fall for the overcomplicate things mindset trap
• Programming can be seen as a way for us to dematerialize by conceptualizing th
  e complexities of the world around us, which is why it should be as verbose as o
  ne can take.
• Write documentation for every types of users not just for your buddies.
• Explain any architectural or design choice that you make. Your position/role/r
  esponsibilities/resume is not an alternative for a rational.
• Intuitive but not repetitive; aims for a progressive user/developer experience
  with well thought and minimal default behaviors. Generics are good but are they
  enough? No, interfaces and workflows in general need to fit their use cases so
  that they can provide both a robust and minimalist solution. Information should
  be made available to the user and requested by none other than himself as oppose
  to information bloating which aim to lay down as much information as possible.
• Think about the stack from the very bottom of it up to the highest heights (is
  it extensible? can it be easily debugged? can things be reversed?).
• Making software is good, maintaining them alive is even better. Learn from the
  past by looking at the state of other OSS projects and what can be done
  (better) to keep things afloat.
• Any software attempting to "solve" a problem bigger than himself should neve
  r be trusted in the first place. I consider Swiss Army knife softwares as evil.
  Do one thing and do it well
• Source code is certainly, without any doubt, NOT a reasonable replacement for
  documentation.
• Try to flow smoothly along whatever specifications govern your ecosystem. No h
  earsay. No rebuilding the entire stack from the ground up, fit in! Don't break s
  upposed edge/rare user cases just because you believe your stuff working is more
  important than not breaking defaults.
• Think add not replace. Reinforcing expectations and fixing flaws in existing s
  ystems is much more rewarding.
• I believe OSS is not much without openness, digital sovereignty and
  interoperability.
• Composability is everything.

What about you? What's your manifesto?