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 obscurity 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 good 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 the complexities of the world around us, which is why it should be as verbose as one 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/responsibilities/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 never 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 hearsay. No rebuilding the entire stack from the ground up, fit in! Don't break supposed 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 systems 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?