# Requirements ### Shared goals Each one's purpose and intention should have a deep alignment with the purpose of the open cooperative ecosystem: * We are working together to **support an economic system that supports human and ecological needs**, not profit. * We implement **non-hierarchical** organisation in both our way of working together and our technology. * We are thinking **long term** but we feel a sense **urgency**. * We think technology is not neutral, and that societal norms can be shifted through **conscious tech design**, so we acknowledge that this often involves developing custom software. * We work carefully to support immediate **user needs** along the way, while moving systematically towards our larger **goals**. ### Interconnected Play friendly with the other apps in the ecosystem:
* Our apps use vocabulary, protocols, and technical solutions for communication between apps that we agree upon in our assemblies. ​​​​​​​
* **Valueflows** is the syntax agreed on for economic vocabulary; other vocabularies can be added as needed. We will also work with vocabulary translators as needed to facilitate interoperability in the short term and to mediate between general ones and vocabularies that need to be more specific (such as food). * **"As much decentralisation as feasible"**: To empower developers to cooperate more easily but also to innovate independently from each other while having access to a shared userbase and user data, and to empower users to choose their preferred apps without being isolated from the rest of the ecosystem. Our medium-term aim is to not rely on any central servers or databases, and build on top of fully P2P platforms where each user controls their own data.
### Collaborative Our developers consistently coordinate with others in the group. * Participate in regular assemblies and ongoing chat. * If unable to participate for a period of time, notify the group ahead of time and turn over work as needed. ### Needs based Our developers work from documented and prioritized needs and requirements from various user groups. We actively involve users in small iterations and regular meetings to co-design together as the software is developed. ### **Open Source** New software is open source from the beginning, preferably AGPL or peer production. ### **Aligned Values** When we use or repurpose existing software, **values and business plans must be compatible** (For example, if the project has plans to close their source, they are not a good long-term bet. Selling user data or giving it to spy agencies would be another incompatibility. Where their money comes from might be another tip-off to values). This does not necessarily apply when 'forking' a project, if we have the ability to maintain and evolve it without depending on upstream developers.
### **Viability & Support** A team of people should be able to maintain the app and support its users. When creating a new piece of software, or using or 'forking' an existing one, **long term viability** should be considered (technologies used, external dependencies, code and documentation quality, labour and expertise required for maintenance, etc).
### **Multi-platform** Designed to support at least desktop and mobile interfaces. --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://oce.gitbook.io/docs/apps-ecosystem/requirements.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.