Collaborative Development Log

Hint: Documenting collaborative development evolution at OSE

Thu Aug 22, 2019

Clear distinctions need to be made regarding the nature of collaborative economic development, in terms of its transformative potential. We ask 2 improtant questions. First, what does it mean to collaborate? Second, how do we handle defection?

First, collaboration means that both parties benefit and that relationship can be sustained financially. This implies financial feedback loops. Ie, a natural incentive of Financial Freedom must be built in, to allow for self-determination as in Self Determination Theory. Thus, if a relationship is based on interests that do not relate to financial freedom, then that relationship may be short lived. Thus - OSE gets paid for its services, and the collaborator benefits financially as well. This is just a fact of survival, in that everyone has a certain cost of living. Practically speaking: OSE's collaborators, if they are to stick around, must contribute to OSE's financial sustainability, and OSE must contribute to collaborators' financial sustainability. This imposes a firm constraint on OSE operations: in its formal operations, OSE the entity cannot engage in work for free. Someone pays - and that 'someone' in OSE's case is a financially bootstrapped enterprise. The work still must be voluntary - as in free from alienation for compensation. That is - agents of OSE would still do it if they weren't getting paid because the work is fulfilling and meaningful.

The importance of the above is that OSE is creating a transparent and inclusive economy of abundance, and that includes eliminating structural evil. Because material constraints are so closely related to structural evil - OSE works on collaborative design to remove material constraints from human existence. Ie, afforest the earth, replace the proprietary economy with collaboration, and move on to human evolution.

Moving on to defection. If we are collaborating openly and transparently to create abundance, is defection allowed? Can defection exist while retaining collaboration? First, what is defection? Defection would be when someone hired by the OSE's open source franchise decides to go independent. The answer to whether this is still collaborative with OSE depends on the details. If they are transparent and follow similar methods of open source product development - then a defection is welcome. Defection would then be like graduating from OSE: if the defector publishes the open enterprises that they develop, OSE and everyone else can benefit from it, and we are still creating abundance. Graduation means that the graduates take on additional responsibility, for which they should be rewarded. Only if they leave from a scarcity mindset, and think they can benefit more by not collaborating (not contributing to collaborative development, not sharing their enterprises) - do they hurt the commons.

Case examples. A defector learns enough to go out on their own, and push a different direction of development - keeping everything open source. They contribute to open source economics by developing distributive eneterprises - especially the support that enables others to start up. This is a clear win for everybody. If OSE invested in the time training the defector - OSE still got paid. In the OSE revenue model, OSE simply follows the first point of this discussion: What does it mean to collaborate? If we collaborate with ongoing built-in financial feedback loops pay, everyone is happy. There is no such thing as sacrifice or martyrdom for doing public-interest work. In fact, all work should be public interest, unless one is an autistic sociopath like a typical open source developer lol.

So to summarize: defection on good terms is desirable. In such a case, this is effectively not a defection, but a graduation to the next level. The main point to consider is - is the defection still contributing to collaborative development for a transparent and inclusive economy of abundance? If so, we welcome it. In another case, when a person goes proprietary, this does not help. When a person goes proprietary - does that hinder OSE's work? I don't think so - we are still free to pursue open development. If our results lead to transcendence of structural evil, everyone wins. So we should be kind to true defectors, as we continue to grow the pie for everyone.

The relevant operational question then becomes - how do we create an infrastructure to meet the need of absorbing new collaborators to grow meaningful development and self-determination in society? What are the business structures necessary? How do we reform any structures in the process if they are contributing even the least bit to structural evil? This is a question of enterprise structure and operations.

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 would like to see something better. To be consistent with developing people, we want to create more entrepreneurs and less employees. So we reach higher by proposing that future companies be smaller - as in the Second Industrial Divide - so that flexible manufacturing prduces a wide array of goods instead of centralized production. We think that the best scenario is where EVERY town nurtures its creative genius via open source microfactories for distributed production. That is like Local Motors, except the process is collaborative, open source, and public interest.

An important note on collaborative: it recently emerged to us that crowd design is highly non-collaborative. This applies to Local Motors and HeroX - - a crowdsourcing, incentive design platform. Examining key projects on HeroX - yields an interesting discovery: nobody collaborates! All the challenges that we could find have a competitive structure where teams compete with one another. In other words, teams or individuals submit entries - and the rules explicitly forbid copying (or building upon) another's work. This is plain wrong, from the last century. Why not design a challenge where you REWARD people for taking others' work and building upon it? In other words - structuring the contest for ALL the entries to collaborate and work together. Clearly there are challenges to collaboration which make competition the default: such as it's easier to do, and tools may not exist for broadscale hardware collaboration, people do not have sufficient self-esteem to let go, and selecting winners is much harder. But we think it's worth the effort to develop a model where large-scale, collaborative, open source hardware design takes over as the new norm.

More: The main challenge right now is to find a business model for true collaboration. We have found that volunteer effort is limited when it comes to product schedule, simply because putting bread on the table competes and typically wins. Proper leadership and management can help - but only to a certain extent if there is no pay. Financial freedom is the only way that pursuit of true purpose is unleashed.

Our model right now is: (1) develop a $10k/month net, replicable model for a distributed microfactory operation; (2) enlist collaborators by offering this opportunity in order to fund a high growth, open source franchise enterprise.

The open source franchise continues product development, maintains standards and certification, and provides a growth opportunity for building OSE Campuses. The enterprise also supports recruiting, marketing, and distribution. There is one critical requirement: the open source enterprise must provide sufficient surplus to fund Incentive Challenges as a route to product development. The key still remains getting the best ideas and products to spread, as a means to transforming the world. A natural outcome of funding pursuit of true purpose is the resolution of pressing world issues - from obvious ones like environmental degradation and poverty - to more subtle ones such as the loss of meaning.

There are challenges, as a higher skill set is required, which means fewer people have the requirements:

edit

The solution to this is collaboration. Structure an incentive challenge by inviting people of all skills, and upgrading their missing skills as part of the process. As such, a rapid learning community must be created, and Educators can be in great part tasked with bringing everybody up to speed. In fact, the prize can be incentivized for bringing everyone along. This can be done, for examply, by requiring that rapid learning materials are part of the project outcomes.

Jumping down into the weeds of where we are today - we can enlist collaborators for STEAM Camps by selling the vision of reskilling the public to help it become more enterprising. We develop open source technology to get there, with the reqiurement of public interest product development as the new norm. To me, the missing link is the vision of possibility. Where we can unleash just massive amounts of human potential.

Now there are immensely complex industrial processes harbored by various companies - and the question is - can we do the same in the open source? Of course: it just means that people share design, improvements are made, and manufacturing improves all together. Ownership and distribution of power improves.

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.