Collaborative Development Log

Hint: Documenting collaborative development evolution at OSE

Mon Aug 19, 2019

Missing from planet earth is broadscale collaborative economic development. There are certain open source projects that are crowd funded and that enter the public domain. In most cases, though, development is still the heroic 2 Pizza Team - as opposed to breadscale collaborative development. There have been broadscale collaborative development efforts in the creative space - crowdsourced vocals with 2000 people producing a melody - by Eric Whitacre. To date, we have achieved the build side of collaborative - such as 50 people building the Seed Eco-Home in 5 days. We see a clear path that this can scale to hundreds, just as Church in a Day has already demonstrated - and further on to thousands for building a village in a couple weeks. But we have not yet seen the design side of collaborative. The closest perhaps was the 6 in 60 campaign back in 2013, where we built a tractor, ironworker, and part of the backhoe - designing and building within that period.

Our method relies on true crowd development - where we take anybody of the street - and if they are willing to learn basic collaborative development techniques - they are welcome to participate in our work. We have not focused on recruiting rock stars - in part because they are less accessible, and in part because we wanted to show that the crowds could achieve more than superstars. This is under the assumption that the cumulative work of many hands can do more than a few superstars.

Others differ. Jobs said that one superstar developer could produce the results of 100. Our own experience shows something closer of 10.

We are committed to a sociotechnical revolution. That is - devloping technology is not sufficient to make a better world. Developing people is also a requirement. Specifically - with respect to their collaborative nature, self-esteem, ethics, creativity, and growth mindset.

Thus, the enterprise we need to develop is a sociotechnical one. One that in its essence - develops the human side. For us - that is primarily collaborative literacy - which allows us to work with and get along with others. We do this by providing the tools and skills for collaborative development. We also do this by developing means to financial freedom via entrepreneurship based on open source technology.

This is why we don't want to create another Prusa Research, Lulzbot, or Tesla. These are all centralized manufacturing operations. As great as they are, we argue that Our model

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 - and lets go of control to design the program collaboratively. The Project Integrator is still the lead stakeholder - but is open to stand aside as long as specficiations are met - and is also open to changing requirements pending better fit with principles. 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 - rock stars bring audiences, lead events, and OSE provides the vision that people want to be a part of. 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.

But one question yet unsolved is the due diligence of distributed production engineering and quality control. This is non-negotiable, simply because it's possible - and it's consistent with an economy of abundance. Such additional emphasis on lean, modular, open source design is a strict requirement. Who loves to prototype? Hackerspaces love to tinker. Students would love to tinker with meaningful stuff. But it takes time. The experienced person is much better positioned. Thus, it is probably the rock star DIYer that saves the day.

Realistically, what can we expect from the rockstar? Definitely awesome point technology. Its integration is the challenge. Perhaps modularity is the universal answer. If we have ready primitives: any machine is made up of a bunch of ready primitives. So we get very specific about the design problems - and solve them together, and rapidly because we are actually partners and very capable.

Working with capable partners appears to be the best solution. See A Players. It feels good, and a lot of work can be done rapidly with A Players. Therefore, the solution appears to be getting the right balance of A Player and rising star - primarily by virtue of mission-based excitement.

Rapid development can come from granular modular breakdown, and focus on interface design that allows the parts to be used modularly - by defining a clear architecture. And using interoperable tools. Start is a clear architecture to bound the problem, and an offer to become part of something bigger.

To summarize the needs:

1. Sufficient organizational infrastructure to handle multiple events
2. Going through the numbers - evaluating a sufficient number of candidates for success
3. Rapid development via modular design.