Product Development Toolchain


This post came from discussions about distributed manufacturing here. @jcm80 @ryanfobel @szroboman_opentrons @kaspar @amchagas @julianstirling @moritz_lablab @regfade maybe missing someone sorry if so!!!


To create a specific TOOLCHAIN (set of connected technologies / procedures) which different hubs can use to produce open science hardware. The focus is on consistency, quality, and building both perceived (branding) and real (product QC) customer trust.

SciBots + Our Sci are going to use this when we start manufacturing together - so it’s make it good! We’ll provide feedback on what worked well and what didn’t in our case. Also recognize we need to be practical about the skills we have, and where we should outsource skills to 3rd parties.


When selecting the technologies in the toolchain, we should consider the following:

  1. Functional - it should do what we need it to do, and do it well!
  2. Usable - it should require as little training as possible.
  3. Accessible - should be usable in most countries at most times.
  4. Supported - the technology should have a long life, and ideally a strong development community
  5. Open source - we should support open source

Sections of the Toolchain


These are the sections of the toolchain which will require a choice of technologies.

Evaluating Potential Products

  • Sensorica’s Review Doc: @tiberiusb from Sensorica (cc’ing @fabioballi from Breathing Games) sent this example document for discussing and evaluating new projects for Sensorica. Really helpful and good section overviews, especially like the groupings of growing consensus, attention, alternatives, etc.
  • Sparkfun’s onboarding doc: Link here. Another good one, lots of good ideas there.

Product Design Tools

PCB design, 3D design, etc. etc.

  • KiCAD - Circuit Board schematics + board layout tool
  • FreeCAD - 3D design
  • OpenScad - 3D design

Assembly Instructions


  • Kitspace - Put your projects in on GitHub/GitLab but generate a page here from which people can more easily buy parts and PCBs.
  • Kitspace BOM Builder - Helps you find the right components, select in-stock ones automatically and then lets you buy everything at once and save the BOM for later. Message @kaspar for access to the beta
  • Octopart - Search for parts

Documentation Standards

  • Open Know-How - A manifest file that lets software and people know what files are what and what the project is about. The aim is to make your project more discoverable.
  • DIN 3105 - A standard that let’s you or others certify that this is truly open source hardware (as of yet unreleased – here’s a video)
  • ASD-STE100 - Simplified Technical English: a controlled language to help the users of English-language maintenance documentation understand what they read
  • oManual / IEEE 1874 - an XML and JSON based standard for storing and transmitting procedural manuals. It is used by Dozuki.

Supply Chain Tools

BOM management, stocking management + SOPs, etc.

For parts and stock management there is Part-DB (open source). It can print barcode labels, keep track of available components and sources & order code of parts. Currently the project is undergoing a complete rewrite.
Part-DB - has a new version out… would love to see an example (none referenced, but clearly used by the community!) -
IndaBOM - also interesting, Django + Python -

Testing instructions

(To check the product for complete functionality)

Use Instructions + Tutorials


Icons, Art, Web Design, Consistent look and feel


Shipping software + tracking

Tech support + Customer service

web-based chat software, end user agreements , etc.

Shop/E-Commerce Site

  • woocommerce - an open source eCommerce plugin for Wordpress
  • Saleor - A standalone e-commerce system built with modern web tech: Python/GraphQL/React

search github for more?. Does anyone have any experience with any?

Advertising + Marketing

email marketing software, customer interaction software (salesforce), advertising options (google adwords), etc.

webstore + stock checking


@szroboman_opentrons hey Chiu - what does OpenTrons use for supply chain management and related? Do you all use a CRM? We’re considering going down that route, but not sure if that level of integration will be important / needed for small batch manufacture.

Anyway, curious to know your toolchain.

Hey @nick!
Seems Lulzbot is going out of business I think this is why you are unable to open their page about the documentation tool. They do have this link to GitHub though: Maybe worth grabbing it while it is “hot”

Hi @gbathree and all,

To add to your mention about Sensorica, that template doc for product design consideration is part of a product development methodology that has been scripted using Sensorica’s NRP (the software we use to manage projects and resources, etc.).

We call that script a Recipe, which can be deployed with a click of a button, creating a series of tasks that people can take to execute the project. One can modify this planning for a particular context, one can also modify or fork the methodology.

For those who are not familiar with Sensorica, its organisational model, we are building an organisation for peer production, i.e. decentralized production of material goods. The model relies on open (source) innovation.

This reference is about methods we can use to design open hardware products. But Sensorica is designing the whole economic model for open innovation and peer production.

To know more, see
NOTE that we are transitioning to a new website, not all content has been
moved to the new place.

We are also having a high level exploration of future IT tools to sustain p2p economic operations. See OVNi 3.0 document. This reflection is embedded into a wider effort to design future Open value Networks, open and network-type organisations able of agency, production and distribution of material and immaterial products (goods and services). See more on the OVN 3.0 document.

1 Like

That’s a bummer to hear, but thanks for the heads up! It looks like our search continues…

@julianstirling @kaspar @amchagas @nick

Nick and I were thinking about our BOM / assembly instructions software… Here’s what we thought.

We really like + want:


Is it possible to use Gitbuilding’s very smart structure with Gitlab’s existing wiki/comments/versioning and an auto-generating bit of code like mkdocs or docsify but making the output HTML structured more like OHAI (text on left side, picture on right, auto-scroll?)?

That would be free, easy, pretty, and serve both as external AND internal parts + assembly documentation (no duplicate assembly docs).

That to me feels like documentation heaven. If the answer is ‘sounds great but that’s a ton of work’ that’s ok, just wanted to at least share our thoughts.

1 Like

We do need to look a bit more into improving the HTML output of the documentation. Hopefully soon there will be a bit more scope for customising the output and making easier to follow step by step instructions.

We can use GitLabs CI to autobuild the git-building into a deployed website. We do this for
so YOU don’t need python. But the python is run on GitLab. We will need to make this easier to set up. We are also hoping that soon there will be a simple windows executable to launch the GitLab stuff without python installs and command line.

As for the pretty auto-scroll stuff. One of the clever web dev people can perhaps weigh in on how hard that is @jc2450 @kaspar. Pretty much all the web dev I do is steal @jc2450’s code and change the content!


That’s really neat!!! Yeah, I think what you all are doing is really spot on, and our concern is always about support and contributions and all that, but I really like the integrated structure of the BOM and assembly docs in an intelligent way.

I think (curious to get opinions of others) the very structured left side = test, right side = pictures of docubricks and lulzbot are spot on. It’s like microsoft word (all options for formatting makes everyone’s papers look like garbage) versus markdown (limited, intelligent options makes everything look nice and neat).

I know it’s not prime time, but should build an instance and start trying it out? What do you think?

I would be really keen for some people to try it out and report back with pain points and bug reports. I think it is really important that we get some robust community feedback, as there is no point developing a tool that no one else wants to use.

Not to discourage you from using and contributing to our open source tool. But you were swarming about Dozuki before and I recently found out they offer a free service to public projects.

I also found out their data model and API adhere to an IEEE standard they developed in 2013 called oManual or IEEE 1874 meaning you should be able to get your data out again if you use it. I also got confirmation from the CEO, Kyle Wiens, that they don’t take out software patents (as I wanted to take a closer look at it but keep working on Gitbuilding).

I’ve only tried it a little bit so far but Dozuki seems like a solid bit of software in terms of the UI. They also have mobile apps, that I haven’t tried at all yet, but might be useful for taking pictures while doing something.

Because of the oManual standard it seems entirely feasible to write a Dozuki->Gitbuilding exporter down the line (the other direction seems harder as oManual/Dozuki seems more rigid).

1 Like

@kaspar does Dozuki do any sort of BOM management? It made me a really nice PDF of what I put in, but I was not able to see any sort of management of the BOM

Haven’t tried it much yet to be honest. I just had a quick go and I found that you add parts under “details” tab when creating a “guide”. You can only add a description and a purchasing URL.

Once I added a part in one guide and made the guide public I was able to easily find it and reuse it while editing another guide.

Well… that’s an honest but surprising answer. @julianstirling what do you think? Should we roll with Dozuki for now and we can transition later? Or is your work close enough we could get there from here?

I am in two minds. I think if you are doing a main project and a side project maybe do the main one in Dozuki as it is ready for the prime time, and to the side one in GitBuilding so we can get feedback.

Of course I would prefer everything to be in an open tool that I wrote, but I don’t want to oversell something half finished!

I agree with Julian. It’s very useful to have people use and contribute towards Gitbuilding but if it’s going to slow you down in making and selling open science hardware, then that’s no good either.

Furthermore, if one of us actually uses Dozuki in anger, we can better figure out what Dozuki does well that we should implement and what we think could be done better. It’s interesting to me because it’s been in development for a long time, so much thought must have gone into how to help people write instructions.

Regarding the portability, we can’t be sure that oManual will suffice to get everything you need out again as I don’t think it’s actually been used that much. I’d advise trying an export early on in the process to see.

Ok - fair enough - we’ll go with it Dozuki for now then. But I really do think what you’re developing, especially if it’s object-referenceable to an actual BOM, would be really really awesome, so we’ll keep an eye to try it out early as well.

1 Like

On the other hand 0.4 of Gitbuilding seems like it will be quite usable for someone comfortable with installing things with python-pip. So like Julian says, give that a go too. :grin:


Another cool feature of Dozuki is what they call ‘multilingual support’ (automatic translation), which is important for a global community such as GOSH. Not sure about the quality of the translations, though…

We are now using google’s translation for our guides, but this seems to be more straightforward.

1 Like

My guess is they are using the Google translation APIs too. I think machine translation such as Google’s may work quite well if you stick to Simplified Technical English, but I’d like to test that out.

1 Like

Translation is incredibly important. We haven’t thought about this as much as I would like as we have concentrated on getting the base software working. We did write a grant application that would have given us time to develop the software faster and one of the core focuses was on translation. Unfortunately, this was not funded so most development is happening in evenings and weekends.

For v0.4, I am doing a big code clean-up of superficial things just to make the code more readable. At the start of the v0.5 cycle there will be a big push to modularise the code so that each function does one well documented job rather than a mish-mash of many things that only I understand. Once this is done I hope that others may be able to start looking into important features like translation.

1 Like