We are not the only reviewers with a high and positive impression. LulzBot TAZ 5 has just been listed in April by 3DPrint.com as the first of the top 3D printers on the market. Just this week, the LulzBot Mini has been named the Best Intermediate 3D Printer by Tom’s Guide. Other distinctions include PC Mag Editor’s Choice this February, a great review in Computerworld in January – and solely 5 star reviews on Amazon.

For OSE, the advantages are that the LulzBot Mini is open source. Because it is open source, one can build the printer from its design files, available for free download (link?). Last year, we collaborated with Aleph Objects and ran a workshop where we built 12 of the older versions of LulzBot – KITTAZ – from a kit provided by Aleph Objects.

Now the moment of truth. Before starting the first LulzBot Mini print, I asked myself – “On this printer with auto bed leveling – will I finally enjoy this as my first experience where I simply click a button on the computer, and a complete print job will come out the other side without me making any sort of adjustment or tweak?” Upon starting a print – the print head wipes itself automatically against a cleaning pad. Then – the machine performs automatic bed leveling. And I printed the Rocktopus sample print just like this:

My hopes were redeemed. It just works. I pay a lot of attention to auto bed leveling because leveling is a process which gave us trouble with all other printers last year, including the earlier LulzBot TAZ. Things would be going fine on a given 3D printer, and then at some random point, the print would fail, typically due to issues with bed leveling. The situation is that if the height of the print head is not at the exact required level for the first printing layer, then the nozzle can clog if the head is too low, or the first layer won’t stick to the bed if the head is too high. This requires the user to watch the start, and abort and calibrate the height by moving the print head across the bed while measuring the height off the bed with a sheet of paper. To adjust the print bed, one manipulates adjustment screws on the base. While this process is easy and quick for experienced users, we found out with 18 interns over the entire summer last year – that this was a significant challenge. Out of our 4 3D printers, we had a max of 2 running at one time and typically only 1 – due in significant part to issues related to bed leveling. Typically, people would just take the easy way out and rely on the working printers without fixing the leveling. Experienced users may laugh at this – but that was our reality when a significant number of people without prior 3D printing experience are let loose on a 3D printer cluster with little oversight. I personally feel that the bed leveling issue is the single item that keeps 3D printers in the hacker world, not in the popular world.

This is all history with the LulzBot Mini because of its auto bed leveling capacity. The print head touches the 4 corners of the print bed upon startup – closing an electrical connection as the means of detection – where depending on these 4 touch-off points – the height of the head is adjusted by the software. To us, that is a significant and critical improvement for making 3D printing accessible to anyone – as something that Just Works.

This is a long way from the early days of 3D printing. It seems to me that the bed leveling function is the single most important improvement that can take a 3D printer from the realm of hackers to the realm of It Just Works. Surprisingly, the 2 leading 3D printers, Makerbot and Ultimaker, do not appear to provide auto bed leveling. Thus, LulzBot appearst to be leading the way with auto bed leveling in the overall world of 3D printers. LulzBot is the first consumer 3D printer that is both open source AND has bed leveling.

Is auto bed leveling really necessary? It’s a controversial topic – and the answer depends on who you ask. See an interesting thread on Reddit. To an experienced user, one minute of bed leveling every so often on a multi-hour print job is not much to ask for. To OSE, auto bed level is absolutely indispensable when you have multiple people using the same 3D printer, especially when the 3D printer users haven’t been trained properly. It’s the difference between having a print created and not having one – or the difference between a machine that is consumer grade vs. hacker grade. I personally do not look forward to whenever I have to level a print bed. How many thousands, if not millions, of hours will have been spent on bed leveling for the 200,000, and growing, 3D printers that ship yearly, if they do not feature auto bed leveling? Auto level should be just a standard feature, because it Just Works.

For those of you steeped in open source lore, you may find it interesting that Makerbot is not currently on some of the lists of top 3D printers. Makerbot, formerly open source, is the goliath that currently holds the largest market share in the consumer 3D printer market. Makerbot sold out to Stratasys in 2013 for $403 million, spurring criticism from the open source community as Makerbot turned from open source to proprietary. One of Makerbot’s founders, Zach Hoeken, shared his insights regarding the negative effect of open source enclosure by Makerbot – formerly the world’s largest open source hardware company:

“Yes, OSHW [Open Source HardWare] is viable as a business model, look at how successful MakerBot is.” If they close those doors, then it would give people who would say OSHW is not sustainable ammunition for their arguments. It would also discourage new OSHW companies from forming.”

My observations indicate that the open source chilling effect of Makerbot’s enclosure is real and undeniable, as Zach Hoeken predicted. I have had several conversations with various entrepreneurs where I was suprised by their generally-assumed-as-true position that Open Source Cannot Provide a Viable Business Model. That is a short-sighted blanket statement. It appears to be influenced by the case of Makerbot. And this negative notion of OSHW is ubiquitous in the mainstream world – if one can read the writing on the wall.

LulzBot is fully open source, and in fact, recipient of the Respects Your Freedom hardware product certification from the Free Software Foundation. You can download official release Mini files here. You ca also download the ongoing development work here. The source of the Cura control software is here.

Growing rapidly, LulzBot is in a good position to increase the open source share of the market drastically. When I visited LulzBot in early 2014, they just got a new factory space. They currently have 75 employees. OSE looks forward to further collaboration with Jeff Moe, LulzBot founder and CEO – as he supports the open source community and is interested in open hardware in general.

It appears to me that the automatic bed leveling function of the LulzBot Mini sets it apart from the competition. It makes our life much easier in terms of eliminating setup time before any print.

Is setup time required when switching spools of filament? To switch a spool, just heat up the nozzle, and insert the new filament into the extruder. Switching to PLA plastic from the initial HIPS plastic test run, there was no issue. I tried a model tube shape to test the stability of printing tall, columnar objects – such as scale model tubing like for our open source tractor. There was no visible wobble in the print at the very top:

The print at rough setting looks like this:

Note that this was done at the fastest, lowest quality setting – we are just interested in scale models, where we are not looking for part strength. And here is a result of a larger batch:

And comments about the print:

The LulzBot Mini can print with many different materials. An extruder for printing with rubber is currently available for the LulzBot TAZ, and is in development for the LulzBot Mini. We plan on 3D printing this extruder once the open source design becomes available from LulzBot. The development version of this extruder – the Mini Flexystruder – can be downloaded here.

For OSE purposes, we are particularly interested in the following applications of 3D printing:

1. Plumbing fittings – custom, low pressure, water tight connections for irrigation ponds and aquaponics.
2. High pressure tractor hydraulics – using rubber printing for high pressure seals, gaskets, and o-rings for hydraulic cylinders, valves, and motors. This blends precision manufacturing with 3D printing for high pressure applications.
3. Scale modeling – prototyping of the Tractor Construction Set and other machines of the Global Village Construction Set
4. Agriculture – printing useful tools such as the grafting tool – which I discussed in a blog post from 2009 when 3D printing was just getting off the ground.

Now what are the disadvantages of the LulzBot Mini? I don’t like that the print bed moves, as this can cause wobble in certain tall objects that are being printed. I have not seen this be be an issue on the Mini yet, but it probably means that the structure being printed can wobble in certain cases, and possibly come off the print platform. This may be true for very thin and tall structures, or for top-heavy structures – where extra support or slower print speed would have to be used to prevent any issues. I’ve seen this issue in the LulzBot TAZ. The only other issue may be that the USB print connection requires one to have a computer connected to the 3D printer for the duration of a print, as opposed to using a memory card without a computer connection. This means that one can’t take their computer with them if they want to leave when a long print job is running.

As far as the sofware, Cura is simple and it works well. I was pleasantly surprised at the bonus visual effect upon opening up of print files. One sofware glitch was that after installing Cura on my Ubuntu 12.04, the computer did not detect the printer through the USB port. Turning the computer on and off solved the connection issue – it appears that the computer must be reset after the initial software install. I then heated up the nozzle via Cura to remove the filament piece that the Mini ships with, then inserted new filament. I began the first print as in the video. The printer brushed the nozzle to clean it, and then the auto leveling took a few second. Then the print started. Walking away from the computer, I had to disable power saving so the computer would not go to sleep.

All in all, I am looking forward to finally having a turnkey 3D office printer for scale modeling – free from any demand of bed leveling. This allows us to run various test-driven design proofs-of-fabrication. It is useful to examine not only how 3D printed scale models of machines will look in physical shape – but also – we can test assembly and bolting sequences of scale models fully before doing so in real life. Before any multi-ton heavy machine is built, there is no reason why a complete scaled-down prototype cannot be not done prior to the build. This seems obvious that this would be a wise thing to do, but we are just now evolving our development techniques to the point where scale model prototyping becomes fully integrated into our workflows as a normal operating procedure.

In order to streamline our development processes, we are creating sets of icons that will grow into a visual pattern language that can be used for anything from conceptual design to machine documentation and other learning materials in print and online. This builds upon Christopher Alexander’s Pattern Language, and our early work on technology pattern language icons.

Using icons as visual aids in communicating ideas helps readers absorb and understand complex information which we expect will lower the barriers to entry even further for people interested in participating and contributing to new and ongoing projects. Another benefit of having these icons will be in making navigating existing documentation more efficient by visually punctuating extended tracts of text and helping readers find the specific information they´re looking for more quickly.

Why not just use icons from The Noun Project (TNP)?

First, the OSE icon set is totally fluid and open source – we upload SVG source files. This way, if you don’t like a particular icon, you can help us immediately – by downloading the icon and editing with open source software, Inkscape, according to Style Guidelines discussed below. We have created a how-to for how anyone can do this.

Although TNP is a great resource, there are many icons, especially of the more technical variety, that are simply not available there.

Another reason we decided to create our own icon sets is that even if we could find all the icons we need they would most likely not share a common visual style. Even small differences in line weight, line endings, corner radii etc, would become especially distracting when using the icons in combination.

Lastly, while TNP´s focus is on establishing themselves as a platform for creators to license their work, we go a step further. We encourage and support people in learning basic vector graphics editing software skills – to create their own icons – more info below.

Goals and next step

Our goal is to create 1000 icons in six months and in the process start building a team of people with the necessary skills to contribute in creating OSE graphics throughout the year. We have started compiling a list of icons that includes development process steps, all fifty GVCS machines, agriculture icons, and safety + quality control icons, among others.

The next step will be to host a crowd sourced effort (design sprint) to generate icons as a larger collaborative team starting next week. To join, please sign up to our Design Sprint team by filling out a skills survey. We send Design Sprint invitations to this list. Future design sprints are announced on the Design Sprint page if you miss the email. If you would like to participate, please go through the Style Guidelinese and How-To below. Design Sprints will be held for the next 6 months starting this Monday, April 12, 2015, 1 PM CST. See Design Sprint page for details.

As OSE’s Graphics Lead, I have created Style Guidelines that cover some general rules and concepts to keep in mind when creating OSE icons.

I have also created a basic tutorial for how to create icons using Inkscape, an open source vector graphics editor software.

We will work through a list of icons, which includes model icons that can be used as a reference for what the OSE icon should look like.

Related reading: Open Source Hardware Documentation Jam and recent blog post on the Open Source Hardware Development Method.

(note: you can re-edit the video above to help us improve it by downloading the image/voice assets and using PowToon software)

To increase our effectiveness in open hardware development, we are creating an Open Source Ecology Working Team on development workflows and standards. This is our Development Method Working Team. To do this, we are collating prior work on the topic of open hardware development and documentation by reaching out to existing open source hardware efforts. We are interested in the comprehensive process of open development, everything from documentation best practices, development workflows, and versioning strategies – to social and economic aspects of the process – such as team building, production engineering, open hardware enterprise development, and many others. If you are involved in open hardware development – please fill out this Survey of Development Workflows and Practices to provide feedback on what tools and processes you use. These results will be mede available to the rest of the open source hardware community.

Some of the qeustions we’d like to answer include:

1. What are the best platforms and practices for documentation? What development/documentation method are the most effective projects using?
2. How to best address new versions and forking in complex hardware projects while not losing any prior development effort?
3. How can open hardware projects support each other in open enterprise creation? How to fund continued development?
4. How to implement a pull request in complex, modular hardware?
5. What is a good method to capture the rationales and whys of design choices?
6. How to build and work with a team to guarantee continuity for the long term in a volunteer effort?
7. How to handle product branding and quality control when a product gains viral replication?

This is just a small sampler of unresolved questions for us.

Our goal is to facilitate open hardware projects building upon each other. One huge challenge in open hardware is essentially that every new build is a fork: tool-chains, component choice adaptations, build facilities, procedures, material sources, and other details may be different when a build is replicated by someone somewhere in the world. All these details contribute to the ‘source code’ of a piece of complex hardware – therefore – if these are different for any new build – then that build is effectively a fork. In order to achieve proper documentation so that future projects build upon all available knowledge – all such ‘source code’ must be documented – and accessible.

In the absence of documentation standards – the source code may not be ‘accessible.’ For example, if existing documentation is not well organized and it is painful to get through – someone may not read it and may start from scratch. Or, someone may not be aware that documentation exists. In both of these cases, it’s as if the documentation did not exist – and people are not building upon prior work. The documentation that exists but is not used or useful does not serve as ‘useful source’ – a term coined by Luka Mustafa of KORUZA.

Unfortunately, not building on prior work is common with open hardware. For one – much documentation is sparse. Design decisions, design rationales, and the Whys of design are rarely visible.

For example – how many hundreds of different CNC routers have been built around the world – and how many more such devices will be built – before a single, robust, marketable open source version of a high performance CNC router is created? The world of open source is plagued by such inefficiency. True, many people hack to have fun and not to meet or exceeding industry standards – but it can’t be denied that a better product is desirable and more satisfying on many levels.

Part of the inefficiency is cultural – but for those hackers of the system who are interested in real change, the overall state of open source hardware documentation and development methods is an issue that leaves much to be desired. To do better, we need adoption of standards, sharing of best practices, a clear way to find open hardware projects, quick identification of licenses, ways to fork and start new projects effectively, mechanisms to execute pull requests in complex modular hardware – and most importantly – mechanisms to facilitate adoption of these standards.

As we develop this for OSE, we think that many of our techniques and practices can be useful to the greater open hardware community.

Discussion

As the video above suggests, open source software development follows standard procedures for which tools and workflows are well-defined. Open source hardware development is a much more complicated process than software, and a coherent set of development standards is yet to be defined. For an overview of how development of open hardware takes place, your can read Building Open Source Hardware, published last December by OSE’s board member, Alicia Gibb.

With open hardware, the process is more complicated. Consider the compiler – the thing that converts the source code to a working program. In software, the compiler is another piece of software. In hardware, the ‘compiler’ includes tools, materials, the fabricator’s hand, and a worskhop space. Hardware is more complicated and expensive to manage. There are logistics, bills of materials, heavy artifacts, instructional videos, budgets – on top of the design files. The ‘source code’ in hardware includes all these assets – not only the designs, but their various descriptions – such as explainer videos and build procedures.

OSE Parameters for the Development Method

For OSE’s needs, here are some points about our approach.

1. Inviting Practitioners – We are seeking feedback from those who are actively engaged in building OSHWA-compliant open source hardware – and are steeped in the subtleties and challenges of documentation, development, its continuity, and its financial sustainability. We are looking especially for those of you who think that open hardware development has reached nowhere near its potential development velocity for accelerating innovation, and who can propose effective solutions. We are seeking feedback from entrepreneurs who are exploring innovative open source hardware business models. We are interested in practical experience more than the theoretical side. In order to join the effort, start with the Development Method Working Team application.

2. Scope – When people discuss Open Source Hardware, typically that refers to the design and documentation of blueprints. This is a subset of OSE’s interest in open hardware, and much needs to be done along this front. However, our scope is much bigger, and includes institutional experimentation of how to change frameworks and systems for facilitating the diffusion of open hardware. We are interested in enterprise development based on open hardware, and organizational innovation in order to bring about more open hardware.

3. Modularity and Granularity – The Mother of All Development Methods could take hundreds of Ph.D. theses to complete. To begin that process, we follow a granular and modular approach. Granularity means that we will seek to break down the overall methodology into small steps. Modularity refers to selecting particular aspects of overall open source hardware development- such as: Basic Documentation Process; Design/Build Process; Enterprise Creation Process – and many others. Thus, this approach will be able to accommodate many different projects and many different project states and complexities. For example, a beginner working on a small project should have access to the most basic design/documentation platform. For larger projects with more complexity which intend to scale their efforts in size and scope – such as OSE – we will have a more detailed, granular, comprehensive process that leads up to open source enterprise training.

4. Working Teams Approach – To develop different modules of the Development Method, working teams will be created. OSE will solicit contributions to the Working Team from various members of the open hardware community. When a larger number of participants joins the effort, multiple Working Teams may be created, and will organize around development of specific Development Method modules. The goal of the Team approach is to guarantee continuity and a minimum amount of effort. At first, the overall Development Method Working Group may be a single group, but once more than 6 team members are available, other groups will be created, and will coordinate directly with other Working Teams.

5. Team Governance – Merit within the Working Team is earned by contributions. Contribution to the Development Method Working Team is open to anyone. Contributions to the Survey of Workflows and Practices involve submitting proposed workflows or individual steps of development/documentation, with procedures for how these steps are carried out. This survey above is the first step. If OSE is interested in adapting a particular workflow or practice, OSE may contact the practitioner of the workflow or practice for collaboration. Contributors should include their email if they would like to be consulted further on their practices or if they would like to get involved in helping OSE develop its processes. The second step will be to discuss the submissions, and to rate these – via a discussion and up-vote mechanism. The third step will be to identify missing steps. The fourth step will be to organize the steps for coherent workflows. The fifth step may be creating templates for executing the workflows. The sixth step may be to create different workflows, depending on the audience or purpose of the workflow. For example, one template may apply to running a Design Sprint, whereas another template may be relevant to a Working Team meeting. The seventh step may involve creating a mechanism for effective version control, forking or starting of new projects. All of this should build upon OSE’s current Dozuki/Wiki development platform, shown below. For each team, the goal is for a leader to emerge such that the Team Leader will then interact with other Team Leads of the Developnent Method Working Team, while coordinating with other Working Teams.

OSE Documentation and Development Platform

Our main documentaton platform is the OSE Wiki. We use Dozuki as a graphical index to provide structure to the wiki. We also use the main website as our face to the world.

The wiki is also a sandbox which anyone can edit freely, except for critical pages such as the front page which are locked. The goal is to allow collaborative content creation, and to allow novices to document and experiment. We use Media Wiki, which is the same wiki as Wikipedia. Because of the nature of the wiki, it’s a sandbox and it is can be a mess. Don’t worry – that is ok. The key thing about a wiki is that navigation, structure, and organization can be added on top of it, either within the wiki or from an external source. Because the wiki is essentially a database, its content can be displayed in many ways. The important part of its usefulness is increasing structure, quality, and organization over time with many people.

For OSE, we are following Modular Design and OSE Specifications. Modular design means that we can track development at any scale: an entire machine ecosystem, a machine, its modules, and possibly components of modules – ad infinitum. We can treat any component of the system or the entire system as a module. This is useful because we can break down a complex product into small, bite-sized chunks or modules that a large development team can work on. When a development structure is standardized so that all the development steps are identified and clear protocols are written for each step – this allows development to occur, in principle, autonomously. When a large team is available, this in principle allows rapid, parallel development. In order to enable such parallel development, we need to know how modules fit together. For this reason, we define the interfaces between modules prior to developing the modules.

Our goal is to show that when we use this development method, drastic compression of development time is possible by highly coordinated crowd swarming. Our goal is compressing 5 person years of development time into 2 weeks of 125 person development time – or 2 weeks of 40 person-around-the-clock development time across the globe in successive time zones. We’ve been amazed to see how some people see no value in accelerated development schedules – but in our case – we look at such acceleration as the key that makes GVCS completion feasible. Historically, we have underestimated the requirements for succeeding at such a development velocity. Personally, with all the interest in the project after my 2011 TED Talk, I thought we would be done in 2 years. That didn’t happen. By now, we’ve seen enough pitfalls to think that we have figured out the secret sauce. The challenges include process completeness, clear definition of protocols, clear requirements, access to collaborative tools, access to building blocks, team building, team leadership, funding, coordination, motivation, and others. Essentially – everything can go wrong, as there are too many moving parts.

Modularity allows for parallel development, but counter-intuitively, it also crashed our documentation on the wiki. When new versions were created, it became difficult to keep track of which modules remained identical, and which ones changed. To explain, examine our documentation and development process for the GVCS:

Machines are broken into modules, and the development process takes place at the module level. The sevelopment spreadsheet reflects the numerous development steps. The spreadsheet contains a step name, a link to the protocol required to carry out that step, and a link to the product. The links all go to wiki pages, and the development spreadsheet is also a wiki page – with an embedded Google Spreadsheet.

The above allows to keep a clean graphical index of all machines, modules, and spreadsheets – while all the development and documentation is found on the wiki. Thus, the wiki is organized effectively via Dozuki.

The trouble comes when a prototype is built and tested, and a new version is begun. Because all work should be saved for learning purposes, at the point where a new version is declared, the old version is locked down and linked in the past versions of our Dozuki documentation platform:

The way the documentation platform stands today, this is required to start a new project or version:

1. New machine and all modules must be set up on Dozuki
2. All new spreadsheets must be created with new placeholder links for work product
3. All old content that remains the same must be copied into the new version. This is as simple as linking to an old version. The only caution is making sure to make a copy of a file if any change is to be made – as opposed to changing files that belong to older versions. This point is what broke the documentation on the wiki starting in 2012 – old versions were replaced with new versions, instead of copies being made for the new versions. New pages were not started in an organized fashion, but instead, old pages were updated. When there were too many fingers in the pie, this messed up the wiki. The current solution is locking down old pages when a new version is declared, so that only the new version pages are editable.

The process of setting up an entire new project thus takes 1-2 hours, plus whatever time it takes to lock down all old pages. Lockdown has to be selective, however – as effort may still be taking place on updating documentation for old versions.

1-2 hours of setup is the best we can do right now to start new projects or versions. Next steps include potentially setting all this up through templates on the wiki, so spreadsheets are eliminated and only the Dozuki placeholders have to be created.

You can see a few more words on the technical design specifications and challenges for the OSE Development Platform here. The big challenge is setting up continuity in a highly agile, networked, autonomous development process. This process consists of micro-contributions, tag-team effort, and ad-hoc effort that have such low entry barriers that they provide a highly coordinated, focused, and complex development path. We would like to break bounds of established organizational forms and funciton in a way similar to the general notions of a Distributed Autonomous Organization.

If the entry barriers are not lowered sufficiently to allow complex, advanced skill tasks to be performed by non-Spartans, then the chances of open source success in permeating the economy shall be doomed for ever:)

Other Notes on OSE Documentation

We hosted a Documentation Jam in 2013. We established a basic taxonomy tag for open source hardware (OSH) projects so that OSH projects can be found more easily on the internet. We would like to take this further by encouraging the OSH community to begin adopting this taxonomy widely so that open hardware projects can collaborate more easily.

As we move forward to build a solid developer community, we will need to develop rapid learning materials on various relevant skills, from 3D CAD, instructional video production, open source documentation, to open design. This is geared at reducing entry barriers to collaborators, and providing valuable skills. We are considering using PowToons as our platform.

The beauty of this is that if it’s worth doing, it’s worth doing badly. Explainer videos are worth doing. To address quality – we are providing the source files – so you can re-edit the video using freely-available PowToon software – and improving the script and animation. That’s the beauty of open source. Tthe source files for the video are found under the above.

What is required to make distributed production happen, as opposed to the wealth disparity growing? The World Economic Forum has identified the worsening wealth gap as the biggest risk facing the world in 2014 – among issues including extreme weather events, unemployment and fiscal crises. The Genuine Progress Indicator, a measurement which includes wealth distribution, is not improving:

OSE’s mission is to create the open source economy. One important question that we ask is how to create business models that tend to distribute wealth equitably? Our method is open source – but in itself, Open Source is not a business model. It is a development methodology. OSE likes open source because it promotes collaboration, cross-fertilization, and innovation. This also means that a workable business model still has to be developed on top of the open source development method for this process to be viable. Standard business models of monopoly capitalism – which have been designed for secrecy – may not apply. A casual observer may conclude that ‘open source business models do not work because standard models of monopoly capitalism cannot be applied readily’. This view is short sighted – because innovative business models can be created to make open source development work. As a business model solution – OSE is proposing the Distributive Enterprise.

In a nutshell, the Distributive Enterprise is a model where we develop enterprises, and give them away for free. We mean shipping real product – where robust business models are created. Ethically and practically, we believe in this and we are developing this model.

Think about it this way: it takes years of development to create a solid and sustainable enterprise. Many companies toil for years to develop their product, and do a lot of reinventing the wheel while they are at it. By the nature of this process, the result can not be optimal – due to the cost of competitive waste. Once a product ships, companies set up castles of protectionism around themselves, from patents to legal and tax ‘structuring’, up to some really foul play. Think of all the companies that make the same, common product. Startup, development, and innovation costs could be reduced significantly if open collaboration existed between all the companies: from product design to enterprise aspects, from sourcing to business model generation and marketing. The intended result of lowered start-up barriers is that an enterprise could break through start-up mode readily – and begin innovating. By innovating, we mean getting a head start on transitioning from business as usual to a regenerative enterprise – a transformative endeavor on a whole new playing field than plain survival. With such collaboration, everybody wins – people and the planet – and products become better from continuous improvement.

What would it look like if OSE could produce turnkey blueprints that can be downloaded for free and someone could start an enterprise from scratch? If both the product design and enterprise design were worked out in the bluerints, a veritable Construction Set could be created for enterprise creation. To explore this, let’s experiment with the Compressed Earth Block (CEB) Press – which is our farthest developed machine to date:

Distributive Enterprise Models for the CEB Press

There are several possible enterprise models for the brick press, from producing machines to houses, and from training producers of machines to training producers of houses. There may be various others, for which we would like to hear feedback in the comments below or on the Distributive Enterprise wiki page. We are interested in how we can distribute production far and wide – while generating revenue – while creating much greater revenue within the community as a whole. Our goal is to create an ecosystem of collaborating producers, where there is more incentive for collaborators to contribute back to the community, rather than to defect and go proprietary. In principle, our Share Alike license requires others to share derivative work, though this may not be enforceable in various cases.

We are concerned mostly with how far we can spread the enterprise by reducing barriers to entry as much as possible, with the constraint that we sustain OSE financially. The reason that we can meet financial sustainability is that we can always produce the thing for which we give away the plans for free. What happens when the market is saturated? As a flexible fabrication operation, we can begin producing other things. So we are in the game of constant innovation. This is feasible in an accelerated, open development scenario. The limit is that we develop a local production capacity that produces many different products. Because open source brings about efficiency – the end result is intended to be a post-artificial-scarcity economy, where human pursuit shifts from survival to happiness. This is under the assumption that solar energy resources – the fundamental fuel of civilization – is abundant like it is today, so materials can be converted efficiently into the lifestuff of modern civilization.

We theorize that publishing plans openly will result in rapid market diffusion of the brick press. My personal guess is that as long as the learning curve for fabricators is no longer than one week, and the plans are available readily for download – that the OSE machine will capture majority market share within a year of the first fabricator training event. There are several assumptions:

1. Our product meets or exceeds industry standards. Check. Our CEB press produces 6 full sized bricks per minute at half of its max power using 20 tons of pressure – or 8640 full bricks per 24 hour period. We still need to develop its functionality at full rated power.
2. Our machine is lower cost. Check. The nearest competitor with the same throughput as our machine costs $52k. Our machine costs $4.5k in materials and about 50 hours in labor.
3. Social marketing channels and other media presence provide us with publicity so the whole world finds out about the OSE Brick Press Distributive Enterprise Edition.
4. We train people to go into business independently of OSE by publishing fabrication plans, and instructions for how to get a fabricator to build the brick press. We publish the full economic analysis of production and market research – and other supporting assets.
5. The market is significant and larger than OSE can handle by itself (about 1000 brick presses per year)
6. Ease of servicing and part sourcing means that the machine effectively has a lifetime design.
7. Localized supply chains are identified by creating a global database of acceptable sourcing options.
8. Complete plans are available readily for download.
9. A training program for producers is implemented, such that anyone wishing to learn to build the machine can do so.
10. A certification program is created such that quality assurance is provided to any operation wishing to use the OSE brand. We encourage people to sell the machine independently, or using our brand only if OSE has certified the qaulity of the product

Here are the proposed business models that OSE is developing with intent to distribute brick press economic activity as wide as possible. Data will be collected to show market diffusion, which can be compared to baselines from other products. We would like to see that this rate of diffusion is higher than any other product in an established market. It should be noted that while most people don’t even know about brick presses and its market is limited, this can still be a valid case study on the market diffusion of a technology. The main reason why so few people build with CEB is because so few people know about it. That is why market creation potential is large – which is one of the reasons why we are particularly interested in “Training the Trainers” of Enterprise Model 3 below.

1. Simple Production Model: This refers to OSE or someone else selling the brick press. With open, downloadable plans, anyone is free to build and sell the product. Taking the blueprints to a local fabricator is probably the easiest way to produce the machine. This way, someone can have a brick press built for them or for sale. If the machine is certified for quality control, then it will have a higher chance of being sold. OSE intends to provide a certification service, or other international standards can be applied. The OSE brand can be used if OSE certifies the product according to transparent standards. Economics: The brick press materials cost is $4-5k, and fabrication time is 50 hours at $25-75/hr labor in the USA. A sale price of $10k could allow the production manager to capture 10-20% profit. A good production manager could probably get their management time down to about 4 hours per sale with experience. Customer communication, sale contract, shipping, production, and quality control are among the production manager’s tasks. Challenges: Quality control and system integration of a large machine. Potential supply chain issues. Liability issues. Opportunities: Good earning potential based on a simple business model.

2. Producer Training: Any competent fabricator should be able to fabricate the mechanical system of the brick press. Some will know how to build the hydraulic system. Not many fabricators know both metal fabrication and electronics, so the controller for the brick press may need to be secured elsewhere. OSE’s training, geared at fabricators or production managers – or any novice interested in building the machine – is intended to provide a complete training on the fabrication process, including marketing and enterprise aspects. Producers will have a chance to be featured on the OSE site for marketing purposes. Economics: To be determined. Challenges: Determining incoming skill sets and adjusting program accordingly. Opportunities: Great opportunity for building a producer and development network, and for finding future collaborators.

3. Training the Trainers: For diffusion of training throughout the world, we encourage the next level: training of those people who will train other producers in other parts of the world. This is intended to saturate the brick press market with open source innovation, providing valuable development contributions back to the OSE ecosystem. Teacher certification and continued education may be part of this program. This is intended for people to work either under the OSE brand – or for starting independent production training enterprises. Economics: To be determined. Challenges: Future trainer skill assessment upon graduation. Opportunities: Great opportunity to diffuse the technology and build global support.

4. Webinars: Basically, a lightweight version of 2 and 3 done via the internet. Economics:Gift economy model: free for the event, and after 8 weeks of time. For a notification with a link, a person subscribes to a voluntary donation. This involves a gift donation and the material is otherwise available for free. Challenge: Setting up a good webinar platform and website. Opportunities: Great way to reach large numbers with minimal effort.

5. Extreme Manufacturing (XM) Model: This is a dual revenue model based on the one day build optimization of OSE machines. Because we follow modular design, we are able to develop a production workflow based on a swarming group build. In this build, groups work in parallel on the different modules, and then the modules are assembled rapidly at the end. OSE’s goal is to compress build time to a day for every single one of its machines, including the house – by using a large swarm of people to do so. Because we are able to organize such effective ‘barnraising’ style builds, a build becomes a fun, immersive, social production event. People can learn welding, electronics, hydraulics, machining, and other skills in an immersive environment. Further, a complete machine is built as a result, and it can be sold. Economics: We have done this for the Brick Press as one example, and collected $5k in workshop tuitions at $300 per seat for a weekend workshop. We sold the machine at $5k net earnings, for a total of $10k net revenue from the weekend workshop. The economics here are quite favorable. This could work for things like a 3D printer – if 24 people participate, the potential revenue is $7200 if each workshop seat is $300 on top of the pure materials cost. With material costs at $500, this could be a really attractive proposition for participants – especially if they build the best design that includes automatic bed leveling. The challenge here is biuilding a high quality, turnkey printer in a single day – which nobody has done yet. From a preliminary study, we assess that this is quite feasible and we will develop production engineering for a 1 day build in the near future. Challenges: The process of running an extreme build is complex and fraught with risk of supply chains, tool breakage, team morale, and coordination of a large group. The skill set required of an Extreme Event Producer is diverse – from fabrication, supply chain management, documentation, quality control, production engineering, technological savvy, organization, to communication. It is difficult to find individuals skilled to run such an event, therefore, an in-depth training program for Event Producers is required. Reliable assistants are required to help the Event Producer. Opportunities: The XM event is rewarding upon succesful build. People learn a lot and make meaningful connections. Combination of production and empowerment training has a transformative effect on many as they recognize their true productive power. The economic model is robust, and demand for such workshops is significant based on peoples’ hunger for tangible skills.

6. Training XM Workshop Event Producers: In addition to running XM workshops, OSE would like to train others to run XM workshops. For this, a curriculum is needed on top of the event organization protocol. Prospective Event Producers first participate in an XM workshop. Challenges: XM workshops are complex events, so effective knowledge transfer has to be refined, and suitable candidates may not be numerous.Opportunities: Spreading the XM workshop far and wide can have deep transformative potential. This can happen by creating the deepest kind of freedom that can come only from tapping one’s material production power.

7. Training Trainers of XM Workshop Event Producers: This is the next layer, along the lines of Training the Trainers. This is the step after we train XM Event Producers.

8. Other?

All of the above have to be developed in detail – especially market research on existing markets. Our questions on the above models revolve around pricing structure, incentive structure, messaging, and positioning such that the above enterprise options remain true to optimal levels of open source collaboration, while providing revenue streams to OSE to sustain its effort and to grow to a fully-featured, open source product development platform.

For OSE’s growth model, we believe that focusing on the hardcore open source production aspects is the route to a transform the economy: by seizing the raw power of efficient production. Such a model is scalable and unstoppable. It allows us to fund new developers as needed to address continuity of the project. The type of collaborator that we’d like to attract is someone who collaborates first on the production floor to understand the practical and organizational aspects of distributive production and enterprise, and who gains a grasp on our philosophy. Then this person joins OSE as a Partner in Production, not an employee, so that our organization remains an agile network organization with minimum overhead. Continuity is guaranteed because our Partners are producing new resources, not just using them. The goal for the network is to create a powerful, agile, collaborative development, innovation, and production platform. For example, if 1000 new brick presses are needed on a week turnaround time – the entire network can meet this demand easily – while this would be impossible with a centralized operation.

Notes on Distributive Enterprise and Solving Pressing World Issues

It may seem that business accelerators are similar to our distributive enterprise concept. Not so – because usually, accelerators create a company whose business does not rely on creating collaborating clones that can ‘compete’ with that company.

If we truly care about distribution of wealth – spreading the best, innovative enterprises around the world is a way to do it. This is what many companies claim they are doing. Typically, their definition of spreading really means colonializing and monopolizing. For OSE, the interesting part of enterprise innovation is reducing the scale of production from megafactories to microfactories – accompanied by a shift from mass production to flexible fabrication. We claim that distributed manufacturing can meet the volume of demand with a large number of producers – similar to mass production – but without certain inefficiencies of scale. Further, because supply does not explode like in centralized operations that need to keep producing regardless of need – there is less waste produced in the world. Allocation of resources can improve.

The limit of flexible fabrication and distributed manufacturing is the end of employment as we know it, as wage labor is replaced with distributed entrepreneurship fed by open source design. End of employment as we know it appears to be anathema to the current political and economic system of subjects funding their own oppression. Yet the new potential wave of entrepreneurial making is the beginning of true autonomy.

We believe that true freedom – the most essential type of freedom – starts with our individual ability to use natural resources to free ourselves from material constraints. It is from this point that the human race has a chance of transitioning beyond power conflicts associated with the provision of material needs. For that to happen, barriers to production have to be lowered to the point that moving electrons (designs) becomes almost as easy as moving atoms. Technology is enabling micro-scale advanced production. At the point where production or material security is no longer a source of power struggle, humanity can transition to autonomy, mastery, and purpose. That is the point where we can make a clear bypass through the dominant industrial, economic, and political paradigms – and create more locally adapted solutions. Anything short of this does not make people happy.

(source)

That’s why to OSE, the future of the economy is the open source economy – and the Distributive Enterprise model is a way to get there.

The Significance of Distributive Enterprise and Relationship to the Global Village Construction Set

Why is DE so important? Therein we have a practical chance to transition enterprise to regenerative enterprise and systems solutions. Think solving wicked problems, similar to Singularity University and Exponential Organizations – but add open source and remove the technofix.

From one perspective, solving wealth disparity is low-hanging fruit. There is enough for all of us: from first principles – the sun shines 10,000 times more power to the surface of the earth than the entire global economy uses today. The reality is that currently, the wealth of our distributed energy source is not distributed well.

OSE’s notion of a regenerative economy is the open source economy. We define the OS economy as an efficient economy, where distribution of wealth also happens – so everyone is happy. OSE’s current practical approach to the regenerative economy is the Global Village Construction Set (GVCS). As we are developing the GVCS, we are innovating on open collaborative development protocols so that any product can be developed quickly. Over the last few years, we have discovered indeed how much of a BHAG the GVCS really is, and what it really takes to get to 100%. We are perhaps 1/4 of the way there as of 2014.

At present, we believe that a 2 week design cycle for a complex machine/product is possible – compressing the effort of about 5 years of human time to 2 weeks via swarming. We imagine something like a Red Bull Creation – but larger, more focused, replicable, self-funding, and with a carefully designed collaboration architecture. For comparison, the industry standard time to design a house is 4 weeks. For a car, the time is 2 years.

Market Share of Open Source Hardware and the Road to the Open Source Economy

For perspective, the current market share of open source hardware is only approximately one millionth of the total economy . This means there is a long way to go for open hardware, because 85 << 3.5 billion.

Let’s rewind. Global wealth inequality is a pressing challenge. The World Economic Forum deemed wealth disparity the single most pressing risk to the world in 2014. Open source economic development – and in particular – Distributive Enterprise – can yield drastic improvements on this issue. Is anyone paying attention to this opportunity?

Concluding Comments on the Nuts and Bolts of OSE’s First Experiment in Distributive Enterprise

There are 2 components to the Distributive Enterprise. The first is its substance – which we call Extreme Enterprise (XE). An extreme enterprise is an enterprise that ships product – and specifically – an optimized, low cost, open source product that is as good as it gets. The optimization includes zero competitive waste – no patents or protectionism of any sort. All documentation assets are available. From design to BOM to production engineering plan, and even marketing materials. An Extreme Enterpise’s efficiency includes social aspects of the Genuine Progress Indicator: by design, it tends to distribute wealth to the populace rather than to concentrate it.

The second component of the Distributive Enterprise is training for startup. Training is desirable so that any entrepreneur who would like to start the enterprise could get the required crash course – an accelerator program focused on distributive good. The entrepreneur is free to pursue the enterprise option either on their own – because all product and enterprise documentation is available – or via an accelerator program that OSE is creating – to minimize barriers to entry.

Who has the incentive to develop all the necessary assets as above? An ethical player like OSE. Is there financial sustainability to such a model? Absolutely. We test the enterprise model to determine if it work. While dogfooding the enterprise as such – we run this enterprise, learn the ropes, and end up with a working business model. Then we add training. As we believe that information wants to be free, we put all of our training materials online. If you want to take immersion crash training with us, we charge you for that. To minimize the barriers for our social entrepreneurs-in-traing – or OSE Fellows – we are evaluating setting ourselves up as a community college such that tuition can be covered via external support – or we can look for other ways to underwrite our Fellows while making the program self-sustaining.

The Distributive Enterprise is a combination of the Extreme Enterprise and training as above. The DE is a business that develops the Extreme Enterprise – up to dogfooding its enterprise model – and then teaches the enterprise to others. As such, the DE is the polar opposite of the monopoly: its revenue model is based on creating competition for itself. The DE model can train 2 types of entrepreneurs: the entrepreneurs who wants to produce as an XE, or someone who wants to dive into the deep end and start another DE. The latter becomes a teacher of other entrepreneurs. The former is solely a producer.

The DE concept can be applied most effectively to common products that are in wide demand, and where current demand is met by some centralized, non-local operation. The DE can bump out the invading colonial, by virtue of community support and based on raw econommic performance afforded by lean, open source XE. There is a huge case for such regenerative economic activity, because relocalized production brings wealth back to communities. Many startups today focus on zero sum games, turking, and other activities that do not generate real tangible value or real transformative potential. As such, DE brings a meaningful option.

The DE can be applied readily to common products with a huge market as opposed to the long tail – products related to the basic infrastructures of survival that are multibillion or near trillion dollar markets: food (food products, agriculture equipment), construction (homes, work places), manufacturing (distributed producution tools, automation), energy (solar, biomass, hydrogen, etc.), transportation (cars). Complex products such as computers or semiconductor fabrication (digital age technology) are not considered here for simplicity, though there is no a priori reason why such enterprises cannot be considered.

There’s a radically viral intent in this concept. Viral such that perhaps we can change the 85 = 3.5 billion.

50 machines of the Global Village Construction Set.

It’s been quite a ride over the last 4 years. We introduced the Global Village Construction Set (GVCS) on the world stage at TED in 2011:

Critics of the open source economy point out that “Open source is a system of development that doesn’t have the requisite positive feedback loops needed to build a viable economic system.” (link) This is a belief held firmly in the economic mainstream – and is the reason why some open source projects turn proprietary once they develop working products – such as the recent case of Makerbot.

At the same time, we’ve been busy innovating open source revenue models that can be built upon efficient production, and showing that they are efficient because they are open source. Contributors continue to work in the OSE community to scratch an itch or for pay – to develop products that meet real needs.

Efficiency is key to making open source technology viable. In December 2012, we have shown for the first time that one of our heavy machines, the Compressed Earth Block (CEB) Press, can be built in a single day. We combined modular design, digital fabrication, and swarm build techniques – for a rapid, parallel, Extreme Build. One Day.

Merry Christmas from Open Source Ecology. See corresponding blog post.

The promise of the distributed approach lies in enhancing access to raw productive power. We have learned that our blueprints are sufficient for someone to download and build machines on their own. In 2011, shortly after the TED Talk, the first ever independent replication occurred:

James Slade from Texas. First ever replication of an OSE machine – the brick press – in 2011. See details.

About a dozen other replications followed, and overall 104 GVCS machines were built between 2008 and end of 2014. Most were built at the OSE headquarters in Missouri. Most were heavy products like the brick press, tractors, and MicroHouses – and there were also a few small ones like the Micro Power Cube, CNC Circuit Mill, and 3D Printer.

Machines built until the end of 2012. All entries in this graph have links to the details – see original document to access links.

We were supported by the Shuttleworth Foundation in 2012 and 2013. We focused on test-driven prototypes in order to develop and test how the GVCS product ecologies fit together, but did not focus on a single completed product. We learned that the foundation support model is inherently non-scalable to world transformation. We believe that we can help scale the open hardware movement to the next trillion dollar economy by self-sustaining enterprise models, not by foundation funding.

In 2014, building upon our Extreme Manufacturing techniques, we developed a social production model that includes revenue from production (sale of a machine) and from skill-training workshop fees. When we produced the brick press last year, we netted $10k from a weekend workshop – and learned a lot while we were at it. This model relies on the premise that we know how to build machines in a single day – so that we can produce an immersive experience around a build. One Day.

The brick press is important because it can potentially be the start of a killer app. If we can produce high performance open source houses at a fraction of commercial costs using on-site material as our building block, then we have entered a $100B market in the USA alone.

We used our brick press to build out living and working infrastructure in 2012. In 2014, we built several modular houses from CEBs to show that CEB construction can be cost effective.

HabLab living units for interns, built in 2012.

Power Cubes run the tractor and brick press for Microhouse 2 in 2014.

Our last build, Prototype 4, featured a design-build collaboration with about 50 people, where we finished an 800 square foot addition, with modular construction, CEB walls, in-ground hydronic heat for $15k. We built the shell and complete roof with insulation in the 5 days of the workshop. The interior finish looks like this now:

Techniques for building a house in 1 day exist, and that’s where we are taking our hybrid CEB build.

Our next step involves taking the CEB Press the last step: a Distributive Enterprise (DE) model. We will be publishing not only the machine designs that have been tested over the past year, but a model of production that allows anybody to build the machine (or have it built) anywhere in the world. This will be a test case for distributed open source manufacturing applied to heavy equipment. The main challenge will probably be adapting builds to local supply chains, which will require developing an open supply chain database. We will publish both the quick-build version that can be cut with CNC, and the older, manually-built version for builds where CNC cutting is not available. See CEB Press Genealogy for the machine versions.

First brick press product release of 2010. See blog post.

OSE’s concept is to distribute production such that the demand can be met by a network of producers, as opposed to OSE trying to capture the entire market. This is part of OSE’s greater goal: creating an open source production ecosystem to regenerate the planet. For the brick press, OSE will test (dogfood) its own production model, while we encourage start-up of other entrepreneurs. OSE will be developing training and a quality control certification process. We propose that large production volumes can be met more efficiently via distributed production. This is important, for example, if an entire region needs to be rebuilt after a catastrophe, then the distributed effort can deliver, say, 1000 machines on a week’s time scale. This would be impossible for a single manufacturer. By developing the CEB distributive enterprise, we would like to test the practicality of the distributed model. We estimate that the existing market for hydraulic brick presses is about 1000 per year. We expect further market creation after full deployment of open source hybrid CEB construction techniques.

Because we think that a distributed production model can be applied to many consumer products and production machines – from cars to houses to organic food – and that for distributed production to work it has to be open source – we think that it’s simply inevitable that open source distributed production will permeate the global economy at some point. The missing link at present is access to open source product designs (many open designs are closed once they get good enough or choose a non-commercial license) and access to localized, open source production infrastructures/facilities. The distributed nature of solar energy as the fundamental fuel and feedstock of sustainable civilization works in the favor of a distributed economy.

Wait a minute, is the economy not rational because of some invisible hand behind the scenes, and our distributive enterprise goals are doomed to fail?

To develop the CEB Press disributive enterprise model, we will return to our Design Sprints to develop all the aspects of the DE from machine documentation to market research and everything in between. If effort allows, we will start addressing the hybrid CEB housing designs. Our release of the CEB documentation is intended for the end of April. We will test a new Design Sprint protocol, where participation is based on commitment to specific tasks of a carefully crafted collaboration architecture. Previously, we held the design sprints without knowing who will show up.

Design Sprint tasks include engineering, concept design, enterprise development, documentation, explainer videos, and many others intertwined into a meaningful whole. We welcome all self-starter super-cooperators to join. Our goal for this year is to host mega Design Sprints and Hackathons where a high level of coordination is achieved for a few hundred participants. If you’d like to participate on the Brick Press, please fill out the Tech Team Culturing Survey to receive the Design Sprint invitation.

Days 38-43

Factor e Farm interns did a lot of prep work for the MicroHouse workshop, which Founding Director Marcin Jakubowski decided to push back to the second week of August due to weather and scheduling conflicts.

A small group of interns teamed up Tuesday to remove the Bob CAT that OSE rented from the mud after a heavy rainstorm resulted in it sinking into the ground Monday night.

Another group of interns worked on cleaning and repairing a 100-gallon metal barrel to use for slurry-mixing. Several interns also prepared a coop on Tuesday for the chickens that arrived that day.
Wednesday’s first order of business was organizing the workshop. The interns spent the whole day sorting bolts and setting up new tool storage systems. A handful of interns came back to the workshop after dinner and continued working past midnight.

Michael Hess and Emily Dixon sort bolts and nuts in the workshop on Wednesday.

Thursday morning, most interns discussed and worked on publicity for the upcoming MicroHouse workshop that morning, splitting up to work on a slew of other tasks centred on preparing for the MicroHouse workshop.

Interns spent the first part of Friday and a couple hours in the evening preparing for the community pot-luck they hosted that evening.

Steel for the CEB Press arrived Friday afternoon. After everyone helped unload the parts and take inventory, those assigned to building the CEB Press began tack-welding.

The pot-luck was a success. Only five people from the community came, but all of them said they had a fun time and enjoyed learning about OSE.

The farm has been here for about a decade, but few community members seem to know a lot about what goes on at FeF. One of the guests said he had been interested in visiting for a while, but didn’t know how he could until he saw the flyer for Friday’s pot-luck.

Hospility Manager Danny Kirk taught two kids attending the pot-luck with their mom how to safely use a drill to make a wooden “robot” toy.

On Saturday and Sunday OSE interns took advantage of their “mandatory” weekend to go camping, cook out and chill.

New intern Charlie Feng arrived on Saturday and will be staying through next Sunday. Another intern, Arif Kivanc Yilmaz, arrived on Sunday and will be at the farm for two weeks.

Two cyclists coming from New Jersey arrived at Factor e Farm yesterday. The cyclists, Nick and Carter, are staying for just two nights. Today they’re help out with the CEB Press before continuing on their way to San Francisco.

Days 35-37

Last weekend’s Power Cube workshop was a multi-faceted learning experience. Workshop attendees Luke and Lourdes Crowley learned the ins and outs of the PowerCube v7 and the Micro Power Cube.

At the same time, the interns learned a great deal about the intersection of planning, organization, documentation, and fabrication.

Moriah Baltz documents Emily Dixon’s work on the control panel of the Power Cube. Photo by Stephen Whiting

Brenna Fitzpatrick, Guillaume Coudray and and Edo Licina assemble parts inside the Power Cube frame.

Instead of ending on Sunday, work on the Power Cube extended into Monday and still has yet to be fully completed. The Power Cube has been completely assembled; however, there is a problem with the engine that is preventing it from operating.

Here’s what is happening:

When someone turns the key to ignition, the motor turns by the starter motor. The motor turns at an expected rate and sparks are created by the spark plugs.

Yet, there is no combustion happening inside the engine. Why might this be?

The battery checks out, the wiring is up to spec, and the fuel pump appears to be operating correctly. Spark plugs aren’t the issue, because Power Cube expert Tom Griffing tested to confirm they worked.

One possibility is the fuel delivery solenoid may not be fully actuating, which means the combustion chambers aren’t receiving gas. This might be caused by the solenoid not receiving proper charge or simply being defective.

Hydraulics are most likely not the problem, because hydraulics work off of the motor, which won’t run.

Fortunately, Tom brought a Power Cube that works with him, which OSE has bought for use during the next MicroHouse build.

Aidan Williamson co-authored this post.

Day 34

On top of celebrating the fourth of July with food, music and fireworks, Factor e Farm also hosted the first day of this weekend’s Power Cube/Micro Power Cube workshop yesterday.

Founding Director Marcin Jakubowski had interns start the day by putting together modules for each part of the Power Cube. Near the end of the morning everyone headed down to the workshop, where guest-slash-Power-Cube-expert Tom Griffing broke down how the Power Cube is built and functions.

Although the workshop is mainly for the interns, two visitors came to participate as well. Electricians Luke and Lourdes Crowley came from New York after hearing about the workshop through an entrepreneur boot camp they went to in Chile.

After eating lunch and watching the World Cup for a bit, the guests attending the workshop and most of the interns headed down with Marcin to the workshop for lessons in grinding, cutting, welding and safety.

In the evening, everyone celebrated the Fourth of July with a (glorious) feast of burgers, apple pie and other all-American dishes prepared by Hospitality Coordinator Danny Kirk.

A group of interns haphazardly threw together a band to play the Star-Spangled Banner, with Emily Dixon on flute, Michael Hess on violin, Clair Sprenger on viola, Victor Macul and Guillaume Coudray on percussion, Moriah Baltz conducting and Aidan Williamson functioning as a music stand.

The evening ended with intense debates about religion, science, society and a whole slew of other topics, after which the interns went to bed and rested up for the rest of the workshop.

Days 30-33

Founding Director Marcin Jakubowski had interns focus their efforts this week on preparing for both the MicroHouse workshop coming up at the end of this month and the Power Cube workshop taking place now.

Victor Macul, Emily Dixon, Stephen Whiting and Guillaume Coudray began overhauling the CEB Press final assembly slide show.

Devin Ward worked on designing a slurry mixer for the upcoming MicroHouse workshop, which Clair Sprenger started creating a SketchUp file for. They also searched the farm for materials to build it with.

The MicroHouse workshop will require OSE to press 10,000 bricks. To prepare for this, Brenna Fitzpatrick and Moriah Baltz tested soil composition around the farm and created a slide show from their findings.

At the Hab Lab, Stephen created promotional video for MicroHouse 3 workshop with Curtis Calkins and Moriah.

Curtis spent all week planning out the MicroHouse. In addition to finding an electrician, plumber and professional engineer to consult with, he also created guidelines for the septic system and made plans for the MicroHouse footing and stem wall.

On Monday Gabriel Elkind filmed the an interview with Marcin for Stephen’s video and put together a presentation on OSE’s digital infrastructure needs on Tuesday.

Aidan Williamson replaced a broken chain on LifeTrac 6 and worked with Devin to create a spooler for uncovering unrusted welding wire. He also taught the rest of the interns how to drive LifeTrac 4 on Wednesday.

Guillaume Coudray drives LifeTrac 4 for the first time.

Additionally, Aidan and Gabriel began testing the CNC Torch Table capacitive height sensor module that remote collaborator Paul Nee created. (Read Paul’s log for an in-depth explanation of how the module works, or search the terms used in the caption below on Wikipedia.)

Paul Nee’s capactive height sensor for the CNC Torch Table. This module, based on the Analog Devices AD7747, receives analog capacitance data and converts it to a 24bit digital value. This data is then sent to an Arduino ATMEGA2560 via an I2C bus.

Danny Kirk built and installed a door for one room in the Solar Cabin on top of his usual responsibilities as the hospitality manager. On top of that, Danny ordered a new oven last month which finally arrived Wednesday.

(Lots of home-made cookies, pizza and bread loaves have since materialized at the Hab Lab.)

Emily Dixon made two batches of pop-overs the day after the oven arrived. :)

The interns took Thursday off to rest up for the weekend’s Power Cube workshop. Velocar inventor Yann Lischetti, who will be running the MicroCar workshop August 1-3, also arrived that day.

Days 26-30

The interns spent Thursday and Friday finishing up the projects they started earlier in the week. Now the Hab Lab‘s soffit is complete and the Solar Cabins are almost ready to be lived in.

Founding Director Marcin Jakubowski left Friday to help a remote collaborator install a newer model of the CEB Press controller.

After what was by far the most frustrating week for interns at Factor e Farm, the team had an extensive discussion about what they want to see changed around a camp fire behind the Hab Lab Friday night.

(I wasn’t here for the meeting. If you’re interested in learning about the discussion, read these notes.)

The interns spent Saturday exploring Kansas City. On Sunday Sam Turner flew back to New Orleans, with plans to return to Factor e Farm later this summer.

That day the washing machine also flooded the bathroom and part of the 3D-printing and meeting rooms. It was messy…

Graham Coffman left for the summer Monday morning, as two new interns arrived: Aidan Williamson, who came for the whole summer two years ago, and Greg Sedderook, who is just staying for the week. Another intern, Michael Hess, arrived Monday.

The interns spent the whole day Monday finishing up what needed to be done on their modules and doing other computer work.

Danny Kirk and Stephen Whiting helped Curtis Calkins create a promotional video for the upcoming MicroHouse workshop, which will last from July 24 through the 29.

Guillaume Coudray works on installing the soffit from on top of the Hab Lab.

Curtis Calkins enthusiastically screws in a piece of soffit with Sam Turner standing in the background.