In 2016, I asked Marcin Jakubowski why open-source collaboration mattered to his building work. He said an open approach let people build on earlier work and include “a design for replicability.”
That phrase put a useful condition on reuse. Making information public was not the same as making the work repeatable.
Give the next project something it can build on
Marcin Jakubowski contrasted a closed project with knowledge that other people could access and modify. In his explanation, prior open knowledge reduced the need to begin each project from scratch.
For another project to benefit, the knowledge has to be usable, not merely available. That creates a practical question: what from this project could the next team understand and carry forward?
Drawings are one part of the transfer
Marcin Jakubowski connected his model with design, constructability, workflow, modularity, downloadable plans, builder training, and local production. Those pieces showed why a file alone could not carry the whole method.
The discussion treated drawings as one part of a larger method. A drawing does not automatically transfer sequence, skill, or the ability to make and install the parts. In Marcin's 2016 model, training and production facilities were part of the proposed replication path.
Open information changes the owner's role
Marcin Jakubowski argued that owners and other close stakeholders could participate more directly when the design information was open and modifiable. His position was that people closest to the project should have access to the design process.
Marcin described that openness as access to modify a design, not a requirement that every owner build it. In his model, most people would still use a turnkey service, while trained participants would run local facilities.
Replication still needed to be tested
Marcin Jakubowski's 2016 plans paired ambitious build, cost, and growth goals with work that was still unfinished. He described future pilot training, technical development that still had to occur, and uncertainty about which participants could carry the model forward.
Replicability was one of the major things he said needed testing. One fast or low-cost build could start that test, but it could not answer the question by itself.
Review what another team would inherit
Take one method your project expects to reuse and hand its current documentation to someone who did not create it. Ask that person to identify the required inputs, sequence, skill, decision points, and unresolved conditions.
Use the gaps to decide what needs clearer documentation or training before calling the method repeatable. The review does not prove the method will scale. It shows what the next team cannot yet carry forward.
Reuse is a design responsibility
Open access can let more people see and improve building knowledge. Replication requires another level of care: the next team must be able to understand the method, adapt it within clear limits, and execute it with the right capability.
The lasting decision is not whether to publish a drawing. It is whether the work has been prepared for someone else to use responsibly.
