OSE Development Guidelines

1. Understand first that our work is open source, OSHWA and OSI compliant. We develop both open source hardware blueprints, and open source enterprise blueprints that we believe are the foundation for an open source, collaborative economy. We believe that collaborative design for a tranparent and inclusive economy of abundance (see Vision) is not an ideal - but rather a prerequisite to a democratic society.
2. Publish early and often - leave a paper trail of all that you do so future generations of developers can build upon it - in the short term and in the long term. Document on your Work Log
3. Understand that anything that you do - you are not working on it alone. This means that you are building on past work. This means that others will build upon it if it is documented. That means even if it looks like you are working on something alone - you really aren't if you document it - so remember to document everything, and behave like you are working as part of a group. We are building a group of thousands of developers who are intended to collaborate actively on large-scale projects.
4. The wiki is our mass collaboration platform. The wiki accepts html embeds of any content whatsoever, including multimedia and manipulable 3D graphics.
5. Understand that anything that you work on in the framework of the GVCS is important and should be documented. If you think that something that you are doing is not sufficiently important to be documented - then you should probably not be doing it in the first place because it is not important. Summary: when working with OSE - work on important work and pressing issues of society.
6. Find out who the points of contact are for each project.
7. Coordinate people on a project using a Kanban board embedded on a given project development page.
8. Communicate actively with the points of contact when prototyping as things can change rapidly, and you may be using outdated information.
9. Know how to track progress on any given project: see the Development Template and Development Page for that project. But at the same time, ask how this fits in a concurrent engineering process of the Second Toyota Paradox, which uses Test-Driven Design and excessive prototyping - while delaying final integration decisions as long as possible in a parallel development process.
10. When getting involved, it is useful to ask existing developers regarding your xyz topic: "Where is existing information about xyz topic published?" Then, it is a good practice to document further information on that page - or if existing knowledge is not published or is incorrect, that information should be documented or corrected.
11. Participate in online meetings and OSE IRC for real-time collaboration

Links

• OSE Development Protocol