Philosophy
The BABLR team believes that great software is built on strong principles. When engineering choices create trade-offs, a system of philosophy is needed to ensure that "why" is captured in addition to "what". Philosophy also provides context for past choices in a way that can empower new contributors and new leaders to pursue the BABLR mission in a decentralized manner.
- Have a philosophy. Consider what is unique about your system of values. Your philosophy should be useful in informing your choices, but it should not be gospel: your philosophy should change and grow with you as you reflect on your experiences and instincts. Record your philosophy and the reasoning behind shifts in it: growth comes from reflection, and progress requires understanding.
- Software should serve people; people should not become servants to software. Developers should seek empathy with their users so that they can design software that enhances users’ creativity and autonomy.
- Be curious. Ask open-ended questions, and make a good-faith attempt to find answers. Embrace the hardest questions: those without obvious answers.
- Use plain language when possible. Seek simplicity through the creation of a unified and consistent terminology and symbology that aids new users’ comprehension and minimizes the cognitive overhead associated with using our tools.
- Build living software supported by sustainable communities. Pay down tech debt. Create new tech debt. Embrace forks. Value resilience over purity, and the Bazaar over the Cathedral.
- Aggressively support the long tail of use cases: seek to create a playing field that is level for the most niche needs and the most generic needs of current or future users.
- Prioritize developer agency, e.g. by allowing developers to optimize their environment for their own process.
- Value stability in infrastructure. Seek to create a durable foundation on top of which a variety of creative endeavors can thrive.