Collaborative Development Log

Hint: Documenting collaborative development evolution at OSE

Thu Aug 15, 2019

To date, we've achieved Realtime Documentation, One Day Builds of Extreme Manufacturing, and have broken down designs according to Module-Based Design. Today we are pleased to announce the STEAM_Camp_Curriculum#Curriculum_Development_Model where we sextuple the STEAM Camp event in order to achieve accelerated product development. In summary - we pool the efforts of 6 rock-star DIY people to produce STEAM Camps. Can it be more than 6? 6 is a manageable number of people to coordinate for an event. It qualifies also as an 2 Pizza Rule. But we can keep scaling by adding additional locations, where we run the event all at the same time. We can have smaller players participate, possibly even cross-subsidized by the larger events to keep economic feedback loops clear and direct - for bootstrap fundability.

We can address the high level items of development of the first 4 days of the STEAM Camp - as shown at STEAM_Camp_Curriculum#Overview_Schedule_Narrative - by calling on the star DIYers and to join as partners with compensation for non-alienation. But the devil's in the details: OSE is an integrated technology set, so we need to translate the work of the stars to a language that fits with OSE. How to do that - is the last frontier of scaling open source product development for us.

The answer may lie in More than 6 as above, with synergy and urgency based on a proposed Camp date.

The 6 instructors, if inspired, could develop details of product integration. Especially if they are quick in design and build - ie, if they can handle OSE Extreme Manufacturing. Joe Justice comes as an immediate example.

Product integration, however, is a mundane task, and must be addressed in a timely manner - based on event date. Typically, financial resources guarantee timing. But for scalability, we need bootstrap fundability of development. What to do?

Ideally, we involve direct stakeholders - people who have a financial stake in the STEAM Camp. Naturally the 6 instructors should be called on to do the integration work. This may work - but what is our backup if a star developer does not have the time? The most precious resource of stars is typically time. One solution is getting lesser stars. People who are still motivated to prove themselves. That could be one solution.

What are the details of capitalization for an event? We first develop the 4 Day Kit for the STEAM Camp - and all instructors are required to use it. The key to success is assuring that this kit is developed well: for the initial phase of STEAM Camps - it's the startup dilemma.

Modularity is a powerful solution. Can we simply run more events, promising to pay more people - where each person's duties are more manageable because we are all working together? Instead of 6 instructors, we get 6 superstars and 6 demigods. The incentive must come from The Spark - and from financial incentives.

I am primarily concerned about addressing New Stable Product Development - the 4 day kits. The second part is the 5 Project Days - which are allowed to have experimental results - with the caveat that all teams are coopeting with possible prize given to a winner - determined at the Product Demo Day (day 9). We give the winner $1000, or maybe 1-3 prize. We also improve the product with every single STEAM Camp. We prepare by bringing relevant parts to the event - and making the rest during the Camp.

The STEAM Camp addresses a self-funding open source product development method - led by stars, and funded by participants. There must be a scalable business model here for this to grow.

To summarize - we simply add players to the team - by building in organizational support infrastructure to arrive at the desired quality of curriculum and kit. We start with A Players to lead STEAM Camps.

The Project Integrator inspires rock stars to collaborate. Admin support manages registrations, ships kits, builds kits, does logistics, answers questions, prepares marketing templates, does automated or semi-automated marketing, etc.

The financial model here appears obvious. And it appears more compelling than the HeroX model in itself, which does not reward cooperation. Crowd sourcing does not necessarily constitute cooperation, as HeroX shows. See HeroX Challenge Analysis of Creative Briefs.