[Discuss] discuss Digest, Vol 10, Issue 104

Bryan Bishop kanzure at gmail.com
Wed Mar 27 03:54:46 UTC 2013

On Tue, Mar 26, 2013 at 10:23 PM, Matt Maier <blueback09 at gmail.com> wrote:
> So you wouldn't recommend STEP because it's heavy and expensive, and you can

I don't recommend STEP for packaging because that feature literally
doesn't exist in the standard. Additionally, there are other missing
elements for the different uses that we have been discussing. For
instance, I think the BOM-in-a-text-file idea is much simpler to
implement, check and communicate, than something in STEP that may or
may not serve the same purpose. This is easy for similar reasons as
the "requirements.txt" in python projects, or Gemfiles in ruby
projects or package.json files in nodejs projects.

> only recommend ThingDoc for the one thing it does. Can you think of any

I think that's taking my words out of context ("only recommend ...");
I already sent out a wildly long list of tons of different formats and
projects that are worth your attention and time. I thought that
thingdoc was worth singling out in the context that I wrote the
message you are replying to.

> tools that aren't too small, and aren't too big, but are just right?

I suppose many of the BRLCAD tools follow that trend. One of their
guiding philosophies has been to break up their tools into small,
well-defined parts that do individual operations very well. This is
particularly obvious in their file conversion utilities ("g2step",
"step2g", "g2png", etc...), although there's something like >300
different tools that they fling around and many of them aren't file
conversion tools, so you shouldn't take this to mean that this concept
only applies to file conversion.

> Or, to put a finer point on it, can you think of a way to say with any
> certainty what "just right" means in open hardware documentation?

I don't think documentation is the same as packaging. When people talk
about "github for hardware", they aren't talking about (just)
documentation-- they are talking about a standard repeatable way of
finding common things inside of an open source hardware project,
mostly files, which yes can include documentation of whatever type; if
you want to propose a specific file to keep track of documentation, go
for it. Show some prototype repositories. That's what elmom did.
That's what I did-- for instance, there's a git repo of Cathal
Garvey's dremelfuge floating around somewhere with some metadata and
open hardware goodness. In fact, all of his documentation was on
thingiverse and none of it made it into the repo. The license would
definitely allow for you to go in and twiddle things to add in the
documentation off of thingiverse to your liking, I would be happy to
look at your concept for where to put things...

> What would a "just right" tool or suite of tools look like? What would it
> do? How would you interact with it? What would be the core functionality?

Dude, I already filled out your survey :-( if you have specific
questions about the source code I've written, in, say, skdb, I am all
ears. But at this point it looks like you're going in circles?

> I honestly don't understand the point of view that there are easy answers to
> these questions. It seems like everyone agrees the open hardware community
> needs better/faster/stronger tools, so at least we have that to build off
> of. But what do we build?

There are already tools being built, people who seem to have a core
understanding of how technology works and how to build it, on what
technical solutions feel right. If you have specific complaints about
these tools, standards and formats, let's hear those complaints
instead of re-affirming each other constantly.

- Bryan
1 512 203 0507

More information about the discuss mailing list