Development Philosophies and Strategies
A few strategies we have for building infrastructure that lasts:
Open and Committed
Aven is liberally open source under the Apache 2.0 license. We believe that a liberal license is vital for widespread adoption of the framework, resulting in the longevity of our infrastructure.
Criticism, competition, and forks may sting, but they are the best way to learn, and are fantastic for the health of our community. We want as many people to share this technology as possible. As a team, we can build robust tools that survive long into the future.
Documentation, examples and video will be critical for onboarding people to the ecosystem. We aim to make all educational materials publicly available.
We pledge to never give up on maintaining this infrastructure, and we hope to see your support in return.
Diversity and Inclusion
We can only thrive by including people of all ethnicities, genders, orientations, abilities, class, religions, and programming backgrounds! When we do, we enjoy a diverse field of feedback and contribution that will inevitably lead to better results.
Our priority should be on mentoring and encouraging women, black, and latinx coders. These are the most egregious areas of under-representation, but we should also support the impoverished and people without access to big city jobs.
We have a philosophy of making slow and iterative improvements to our existing technologies in order to fix our problems. Rather than recklessly discarding inferior abstractions, we can build long-lasting systems by providing graceful upgrade paths to new technologies.
One technique is low coupling, high cohension. The Aven framework intends to be a set of independent, loosly coupled technologies. This allows people to gradually opt in to the framework as it matures.
We aim to make our technology immenently useful in production. We cut corners when necessary to get products out the door.
To mitigate against shortcomings in our abstractions, we install escape hatches that give us access to underlying APIs. We see what use-cases force people to escape, and use that to inform new and revised abstractions.
Every use-case is valid. We aim to support developers saying "yes" to every product need. We hope to always say yes to questions like "Can you build an iOS app with Push Notifications?", or "Can you program a robot?". When new use-cases emerge, we want to be ready for them, without tearing down our existing infrastructure.
When possible, we share technologies across different environments to achieve the same thing. Where possible, we only use one programming language. One view framework. One navigation system.
Aim to minimize conceptual overlaps. By focusing on a small set of tools, we can make our skills more portable on different environments. Avoid tools that lock us down to a single environment.