Criteria for a Successful, Collaborative OSE Project

When engaging in a development project with OSE, keep in mind these points when doing your development, design, and build work:

Open Process

1. Are you documenting? The key to open source work is building upon others' documentation. If your work is not documented openly in the cloud at a public site - it effectively does not exist from the standpoint of zero-barrier, global collaboration. Is your work on your Work Log? The Work Log on the wiki is OSE's most basic documentation venue for documenting one's work - such that other team members know where to find others' contributions over time - to promote collaboration. Wherever your work is located - have you communicated to the rest of the OSE community where your work can be found?
2. Working open source style. Are you publishing early and often (good)? Are you publishing 'as soon as you have a milestone reached' (not good). The key to working openly is that you disclose all of your work publicly as soon as it is generated - meaning that you work in the cloud - and allow others to help you make the road by walking. This allows for feedback and collaboration to happen immediately. When you publish a Google Doc, are you remembering to Share it immediately for anyone to view and comment? Are you opening Google Docs for edit to the world (good if you keep backups)? Does your work merit creating infographics via our Media Manager's assistance?
3. Past Work. Are you aware that past work has already been done on the topic? What measures have you taken to find, study, and build upon that work? Have you updated the documentation of the past work, and communicated how you are building upon it or moving beyond it?
4. Team Effort. How are you working with the rest of the OSE community?
5. Leadership. Is there sufficient leadership and planning in your project to make it a success? Is this plan published? Have you thought about communicating to OSE leadership about your work? Who are the key OSE developers relevant to your work?
6. Organizing your documentation. After you began documenting your work openly, are you taking any measures to organize it on OSE's platforms so that it can be easier to find and build upon?
7. Feedback. What mechanism have you established for receiving feedback on your work? Have you considered an update on your status on the OSE Facebook page? Is your work newsworthy for OSE to write a press release?
8. Cost - have you considered the cost of a project, and do you have a rough estimate of materials, supplies, overhead, and labor costs?
9. Design for Fabrication - have you considered how the project can be built in the simplest way? Have you consulted with others who have more experience than you in builds to solicit feedback?
10. Long Haul - OSE is in it for the long haul on the time scale of decades. It may take 2 decades for the open source economy to be fully established. What does it mean? It means 50 GVCS technologies are complete, and due to their generative nature - provide the backbone of a parallel economy - the open source economy. The goal of OSE is to contribute to 2% of the world's economy, or about $1T per annum, in terms of value generated from open source knowhow as organized by OSE. So when you contribute to the project, are you considering what your work accomplishes in the long term? And if you have, how is your work relevant to immediate milestones along the rollout plan?

Technical

1. Product Ecology. - What measures are you taking to makes sure that your work fits within the GVCS Product Ecology? Are you familiar with the GVCS Product Ecology?
2. Construction Set - Are you designing your machine or component to function as a piece of a construction set, not as a part of a dedicated machine? What specific features allow your design to be a Construction Set? What features are missing that limit its features as a Construction Set?
3. Parts Library - are you contributing to the OSE parts library? Is your design robust and general enough to merit entry into the OSE parts library? Are you aware of the criteria that allow your design to enter the OSE parts library?
4. Test-Driven Design - Just like documentation should be published early and often - are you publishing your builds early and often? This means - are you doing quick prototypes for testing along the way that allow you to test various features of the complete design? Are you doing scale models, simulations, or CAD to help verify your work?
5. Modular Design - how are you building on existing OSE modules? Do you know which modules are currently accepted as generally sound in OSE's work?

Replicability and Scalability

1. Replicable parts sourcing - Are you providing turnkey parts sourcing for replicability worldwide? If this is impossible, are you building in ways that these parts can be fabricated in house?
2. Simplicity - Is your design easy to understand, build, and maintain? Have you considered what it would take to simplify your design?
3. Worthiness of Replicability - Have you asked yourself if there is sufficient value in what you proposing that make it desirable for widespread replication? Are you trying to address essential needs?
4. Human Service - Does this provide essential value to others? Are you considering that what you are doing should have wide relevance to a larger audience, instead of small, special interest communities?
5. Economic Significance - Is there essential economic value to what you are doing? Have you considered an economic model for production? Have you considered the social and production model by which this could happen?
6. Scalability - Have you considered whether the economic model of production of what you are doing can scale to vast audiences worldwide by distributed production? By DIY production? By commercial production?
7. Design for Fabrication - Have you considered simple and efficient means by which your design can be produced? Have you considered techniques of production that you would like to use, and optimizations in the production process?
8. Robustness - Is your design good? Do you have a pathway to making it good? Is your design lean and efficient?
9. Sustainability of Effort - Are there resources available to sustain the effort? Can you assure that the resources will be available to continue development in the future? How much time can you commit to this before you move on to other things?

Leadership and Organizational

1. Roadmap - do you have a roadmap and budget for where you are going? Is that road map consistent with OSE's roadmap?
2. Project Ownership - Are you clear about who is responsible for completing a project? Do you know that your responsibility as project owner is to collaborate with others and not make unilateral decisions? Do you know what your allowed budget is? Do you know who has the ultimate veto power if there is controversy?
3. Project Completion - When you start a project or get involved in something, do you know the definition of done? Are you clear about who the project owner is? If your work is part of a larger project, do you know who will follow up after you? Is there a transition plan? If you are blocked, are you continuing to pursue the project, or dropping it so it is not completed? Is there clarity on the timing within which a project should be completed?

Ecofriendly

1. Lifecycle - Have you considered the lifecycle of your design? What parts of your design end up in the garbage at the end of their life? How can this be mitigated?
2. Local Sourcing - what local resources are you using to build your artifact?
3. Materials - are you using local, environmentally friendly, safe, nonpolluting, nonhazardous, noncancerous, nonexplosive materials and protocols?
4. Ecology - How are you closing material loops so that product of one step is feedstock for another?
5. Minimum Set - How are you promoting multipurpose design where one artifact can serve many functions, and thus you need less to do more?

Safety

1. Tool Authorization - have you been trained and authorized to use the tools required to do a build/make something happen? Is that validation documented?
2. Safety Features - Have you built in standard safety features into your design? What are these? Are there others that should be added?
3. Murphy's Law - Given the aim for widespread replicability - have you considered the crazy use cases that may make use of your device dangerous? Have you thought deeply about nonstandard things that can go wrong, and how these can be mitigated to assure safety?