Product Development Toolchain

General
1

THIS IS EDITABLE - PLEASE EDIT + CONTRIBUTE!!!

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!!!

Goal

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.

Considerations

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

ADD ITEMS HERE ESPECIALLY!!!

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

  • Dozuki - Developed by creators of iFixit, used by Prusa and others. The platform itself is closed source but itā€™s free to use for open source hardware. It adheres to the oManual standard meaning the data should be exportable.
  • Wikifab is a similar system (seems to be in the process of renaming to dokit.io) (open source? [2] ā€“ expensive?)
  • GitBuilding/BuildUp - Not yet ready for the prime time. This is the work of @julianstirling, @kaspar, @rbowman. GitBuiding is program which turns Markdown with added metadata (Which we are calling BuildUp) into normal markdown with auto-generated bill of materials. It has a built in editor and a will create static website for documentation (Example). We donā€™t recommend this yet, but we hope people can try it and tell us about pain points.
  • OHAI-kit - The tool from the Lulzbot folks. open source, but Iā€™m (Nick) having some trouble getting their page to load at the moment :-:zipper_mouth_face: .

Electronics

  • 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!) - GitHub - Part-DB/Part-DB: Open Source Electronic Parts Database using PHP and MySQL
IndaBOM - also interesting, Django + Python - GitHub - mpkasp/django-bom: A simple bill of materials app built using the django web framework.

Testing instructions

(To check the product for complete functionality)

Use Instructions + Tutorials

Branding

Icons, Art, Web Design, Consistent look and feel

Shipping

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

6 Likes
3

@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.

4

Hey @nick!
Seems Lulzbot is going out of business https://hackaday.com/2019/11/12/the-past-present-and-uncertain-future-of-lulzbot/ I think this is why you are unable to open their page about the documentation tool. They do have this link to GitHub though: https://github.com/alephobjects/ohai-kit Maybe worth grabbing it while it is ā€œhotā€

5

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.).
http://nrp.sensorica.co/accounting/view-stream-recipe/250/

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 www.sensorica.co
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.

2 Likes
6

Thatā€™s a bummer to hear, but thanks for the heads up! It looks like our search continuesā€¦

7

@julianstirling @kaspar @amchagas @nick

Nick and I were thinking about our BOM / assembly instructions softwareā€¦ Hereā€™s what we thought.

We really like + want:

Soooooā€¦

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.

2 Likes
8

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 https://openflexure.gitlab.io/openflexure-block-stage/
from
https://gitlab.com/openflexure/openflexure-block-stage/
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!

2 Likes
9

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?

10

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.

11

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
12

@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

13

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.

14

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?

15

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!

16

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.

17

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
18

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:

19

Hi!

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.

gif
gif800Ɨ600 133 KB

1 Like
20

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
21

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