Producation

From Open Source Ecology
Jump to: navigation, search

Steve -

You mentioned that we should work only with builders for the October 10 build as we need to confirm the 'exact enterprise model that anyone can use' so that we grow and scale, and solve housing. But I would argue that solving housing will not happen unless more people (than just builders) get involved in building housing. Humans are the only species that outsources house building to others than themselves. Therefore, converging onto the long-term vision: more people transitioning from passive consumerism - must be a general long-term goal. This is what differentiates us from people like Musk and any other person who believes in scarcity-based business models. Tendency towards prosumerism and producerism is a good thing, as the crisis in society today has a huge fraction of people feeling powerless, as they lost their creator nature. Video game and virtual substitutes cannot fill this gap. So the only way is spreading productive potential far and wide. Distributing production capacity (and lifelong learning) addresses the China question, Russian authoritarianism, global warming, and other core issues identified as pressing.

If we teach the Seed Eco-Home enterprise to many people, that is good. We would provide ample supply of more affordable housing. But we also want the entrepreneur that we teach to involve others in the build. This would mean that many more people are exposed to building, and we solve housing more easily (it takes all hands on deck). I know that nobody wants to build housing - construction is hard. But I think the way to solve housing would need to involve both builders and people who don't do building for a job. For this reason, involving the public in builds is desirable. One could argue that more effective and quicker training (for scaling the building operations) occurs when non-builders participate. Non-builder such as a DIY person or someone who can do it part time, say in high school, etc.

This leads to the question of what exactly the enterprise business model that we are selling is, and which will be dominant:

  1. Business Case 1: Solopreneur builder without swarm crew - builds 4 houses per year, net revenue of $200k/year.
  2. Business Case 2: Builder who follows the 24-person swarm model - builds 50 houses, net $2M per year.

I think 1 will predominate - as 2 requires a significantly more investment in recruiting, training, and leadership - much harder than 1 due to the added element of leadership/management skill.

Thus, to 'prove the model' - we would need to do 1. But that's not what we are doing. We are proving the model for 2 (which also proves Model 1). And with 2, I think this warrants added non-builder participants in build event to:

  1. Introduce more builders to collaborative swarm builds, which is good for society - as invariably more will get involved, and involvement would mean tendency to lower cost housing.
  2. This is aligned with our production/education model - we never just produce - we emphasize lifelong learning.
  3. We are generating more builder candidates - which we can train-as-a-service - so that more 24-person swarms can be created. Is see OSE training crews for other builders as part of the OSE product offering.
  4. We are transforming education, in that one would not go to tech school or college to learn skills, but they would learn to applied skills and problemsolving to building specific products - which is a model of education of the future (beyond the current broken model of training 'production line workers') because our model is much more purposeful in solving real needs

I think for scaling - once we show that the basic build model works - our bottleneck would become how fast we train new builders. This is highly related to transforming education, as we create many opportunities as a school, not a manufacturing company. The clarity here is that we are an education business, not a production business.

So, is it consistent to include some novices in the build? The bottom line is measuring time of production under a real scenario of 5 day builds - necessary for OSE scaling. This I could envision as scaling to the nominal 10,000 campuses worldwide. I can guarantee this intent, but I cannot guarantee the success of Business Case 2 for many other people - initially. It's too hard. It may or may not happen - yes I can see it happen for a few top dog entrepreneurs - but I think it's in general too hard for a lesser entrepreneur. I can definitely see a few ambitious entrepreneurs try to corner the market with Case 2 - which would be great as the work would spread. We would keep any potential monopolization in check - OSE existence and growth would ensure that distributed enterprise grows and improves, as it cannot be cornered. But I do think a strong stakeholder/Steward like OSE is necessary - otherwise you will get Linux: common core, but no collaboration between enterprises on the distribution of good enterprise - all the players try to corner the market. OSE must thus maintain the common core, AND the distributive enterprise practice.

This is where the excessive emphasis on teaching and distributing economic power must happen on our side. I think part of that - is why we involve non-builders in builds - to share the experience far and wide. And make people appreciate hard work, and skill them up - and show them that it can be fun because our collaborative builds such as the 2016 build were quite fun whenever there is enough hands on deck. That number was 48. This was the most fun event for me that we did. Come to think of it - the number 48 is that ample number where there is so many people that it is quite fun because there are so many hands to help - for a project on the scale of a house build.

So here is my case for including the public in the first build. But, we have to be clear where we are: we are proving Case 2 (which I don't expect to scale as much as 1, though I can be wrong here). By proving case 2, we automatically prove Case 1. I am pretty sure that Case 1 is the one for the general public, while case 2 will be more rare. To build 1.4M houses that are built each year in the USA, our 375 chapters (share of the nominal 10,000 based on US population) would do about 20k of those - but if our campuses grow to substantial house-building effort (why not, because it is an integrated enterprise that will include many other allied technologies) as the 240 person campuses with nominally 200k houses built per year - we are still just doing a fraction of the overall potential. This is where the rest will likely be done by people who we teach - and once we get good at teaching - I think Business Case 2 may have a large share just as I expect Case 1 to have a large share of builds initially.

Anyway, we're solving for Case 2 for OSE purposes - and Case 1 for the public initially, and Case 2 for the public eventually.

I think the swarm 24 build model also provides the education and recruiting function if we include novices - a good thing. I think the case for involving the general public is our vision - of transforming the world to a transparent and inclusive economy of abundance. Note also that this makes us fit more closely within the nonprofit corporate model - which will help us be in legal compliance within the education function as we scale. As long as we are core in education - we are good in the non-profit corporate form.

Now, in the first build, does it hurt us in proving the model if we have novices involved (outside of core 24 builders)? Not if we still collect data on overall build time, and succeed. The 24 builders gurantee our success. As long as they are extras, and not the core - I think they only help the business case - because even now we will be recruiting for the Apprenticeship - intended to start in March 2023. And, it will give us data points for OSE success of involving novices in our core swarm build model - which is how I would design for growth. I would design the enterprise so that any build can be executed with 100% novices - or 100% skilled people - and anywhere in between. This would provide so many more opportunities, such as huge unskilled swarms in crisis scenarios etc. By involving novices - we get a solid stream of candidates to become potential apprentices. Because Case 2 is what OSE wants to do - we want to prove for that - as a sure bet way to have a robust produ-cation (production/education) model - that is what we would thus be designing for in future replications as others copy us. In which case copying us makes our copyers comply more with OSE principles - and these 'defections' are a favorable thing for OSE.

I'm afraid that many people will just go off on their own otherwise (not a produ-cation model), and not contribute to the common core. This has not happened in software - many contribute to the common core. But I think the needed innovation is on the business models and product ecosystem integration - the technology is easier. Linux showed that this has not happened - people don't collaborate on enterprise. Thus, judging by the history of Linux, and my experience in open hardware (I know of not a single open hardware enterprise that collaborates with others on replicating or product improvement once the product has reached market) - there is a strong case for a strong education function in the enterprise. Ie, disseminating Case 2 without emphasizing the education function could lead to replicator non-collaboration, or business-as-usual. Being proactive, I would design Business Case 2 with a strong edu function - implemented not just in our apprenticeship - but as part of the build - ie, making the builds open to the public.

So I would propose that we include a public event announcement, and have 24 skilled builders - but also some novices - up to 24 for a total of 48. We make sure we have 24 builders - the public workshop is just icing on the cake, and it also produces extra revenue to help bootstrap and grow.

That is a huge level of innovation, I think we have to be clear on the need for education. So let's nail the clarity on this point tomorrow when we speak.

Marcin