Open hardware directory part 2
Bryan Bishop
> One thing that bugs me is the lack of a reasonably complete,
> annotated directory of open hardware designs, preferably with some
> sort of license description or "what makes it open in the first
> place"
"You click and it opens up the design no questions asked" is a good
start. Let's work from there.
> I've seen these two lists, but they aren't even close to complete:
> http://en.wikipedia.org/wiki/Open_hardware
> http://www.p2pfoundation.net/Product_Hacking
<snip>
> So, what makes something Open anyway? We really should start drafting
> some kind of set of principles like these:
> http://www.debian.org/social_contract#guidelines
> http://www.opensource.org/docs/osd
>
> That's what mailing lists are for, right?
I'm not so excited about writing that sort of social contract. Maybe
somebody else can start that and I can go yell at it. Anyway, what
about the mechanics of that sort of directory, that too is important.
Maybe a few words could be said about its distribution and sharing. For
instance, debian has a good number of mirrors, as well as any other
highly used project, such as sourceforge, kernel.org, etc. This is more
out of necessity than anything else, but plans for "open growth" might
be appropriate here, such as some pledges of people replicating
repositories for prosperity over the internets?
- Bryan
________________________________________
http://heybryan.org/
Engineers: http://heybryan.org/exp.html
irc.freenode.net #hplusroadmap
Christian Siefkes
> On 2008-09-30, ben lipkowitz <fe...@sdf.lonestar.org> wrote:
>> > One thing that bugs me is the lack of a reasonably complete,
>> > annotated directory of open hardware designs, preferably with some
>> > sort of license description or "what makes it open in the first
>> > place"
>
> "You click and it opens up the design no questions asked" is a good
> start. Let's work from there.
A collection of free/open design is planned in the Appropedia. This was
initially announced as a stand-alone project, the "Universal Production Set"
(UPset), see
http://www.keimform.de/2008/09/04/hiddinghausen-talks-1-free-design/ . After
some discussions, it was decided to make it part of the Appropedia. An
overview, including a draft template for project descriptions, is available
here: http://www.appropedia.org/Universal_Production_Set .
Technical basis shall be MediaWiki (since that's the software basis of the
Appropedia) with the Semantic MediaWiki extension. Currently, the project is
stalled a bit, while waiting for somebody who can do so to install Semantic
MediaWiki (and I was, in any case, busy elsewhere), but hopefully it will
soon be rolling again...
Feedback is welcome, especially on the template -- what else should be
included, which fields are unnecessary?
Best regards
Christian
--
|-------- Dr. Christian Siefkes --------- chri...@siefkes.net ---------
| Homepage: http://www.siefkes.net/ | Blog: http://www.keimform.de/
| Better Bayesian Analysis: | Peer Production Everywhere:
| http://bart-project.com/ | http://peerconomy.org/wiki/
|------------------------------------------ OpenPGP Key ID: 0x346452D8 --
I love deadlines. I like that swooshing sound they make when they pass by.
-- Douglas Adams
ben lipkowitz
> Bryan Bishop wrote:
>> On 2008-09-30, ben lipkowitz <fe...@sdf.lonestar.org> wrote:
>>>> One thing that bugs me is the lack of a reasonably complete,
>>>> annotated directory of open hardware designs, preferably with some
>>>> sort of license description or "what makes it open in the first
>>>> place"
>>
>> "You click and it opens up the design no questions asked" is a good
>> start. Let's work from there.
>
> A collection of free/open design is planned in the Appropedia. This was
> initially announced as a stand-alone project, the "Universal Production Set"
> (UPset), see
> http://www.keimform.de/2008/09/04/hiddinghausen-talks-1-free-design/ . After
> some discussions, it was decided to make it part of the Appropedia. An
> overview, including a draft template for project descriptions, is available
> here: http://www.appropedia.org/Universal_Production_Set .
What I meant by "complete" was not in the sense of "this covers everything
we will ever need to build" but rather "what are ALL of the open hardware
projects in current or past development?"
I regard the first concept as somewhat insulting as it assumes that the
creator of this list knows what I'm going to do with my life. That said, I
would be very grateful if a fully furnished Dymaxion house were dropped in
my backyard. But I think it's likely that before long I would start to see
improvements to the design, and want to hack away at the hermetically
sealed control circuits.
The "Don't do harm principle" is a bunch of crap. Please don't infect the
memespace with your irrational fear of nuclear energy. Some of us might
need it. Next you will be restricting designs based on synthetic biology
because of the possibility of creating super viruses or mind control.
Carrying this train of thought to its logical conclusion, you end up with
the Nanny-state we currently live in, where one can't even buy common lab
reagents without permission from Daddy-government. Stern-faced librarian:
"Why do you want to know about <insert any technical topic here>, planning
on making a weapon?"
This arbitrary restriction also conflicts with "No Discrimination Against
Fields of Endeavor" condition in the Open Knowledge Definiton.
(while i'm on a cranky flame-roll:)
Why only 8 "Essentials"? Did you pull this number out of a hat?
Everyone has their own idea about what is "essential" and it can take lots
of harsh criticism to reveal one's silly ideas. I'd argue that "not dying"
is the only essential, but many people will disagree with even that.
Emergency care
...
Books, music, movies, shows
You aren't enumerating a set of essentials, you're making a taxonomy of
consumer infrastructure. I'd rather have a taxonomy of infrastructure in
general, and have human infrastructure be a subset of that. Of course we
might just be living inside a hollow sphere where space shrinks the
further you get toward the center..
"Production shouldn't require expensive materials/components/tools or rare
skills, whenever possible." but some things _do_ require them! Perhaps you
should rename your project "Basic Production Set" to reflect its assumptions.
Anyway, thanks for getting something up on the web for us to look at.
-fenn
Mike Harris
are times when nuclear energy is fine, and guns don't kill people,
other people do; keeping information from people will just keep them
from being able to defend against it (i.e., how do you test a bullet
proof vest without a gun?)
The eight essentials should be a subset themselves, the vast majority
of the designs probably wouldn't be for finished products but, say, an
industrial furnace that can make things in any of those categories.
As for the template, I think it could be more ad hoc. Those look fine
as a guideline, but I don't think you'll get many people filling in
the "goal" type fields. An example of some categories I made for the
fledgling openvirgle project:
http://www.oscomak.net/mediawiki/index.php?title=Special:OntologyBrowser&src=toolbar
I think you have to create an account to see that, so perhaps just the
category page would be better:
http://www.oscomak.net/wiki/Special:Categories
The point being, a lot of the types of categories people would want to
search would be things more like "basalt fiber processing".
On Oct 16, 4:32 pm, ben lipkowitz <f...@sdf.lonestar.org> wrote:
> On Thu, 16 Oct 2008, Christian Siefkes wrote:
> > Bryan Bishop wrote:
> >>>> One thing that bugs me is the lack of a reasonably complete,
> >>>> annotated directory of open hardware designs, preferably with some
> >>>> sort of license description or "what makes it open in the first
> >>>> place"
>
> >> "You click and it opens up the design no questions asked" is a good
> >> start. Let's work from there.
>
> > A collection of free/open design is planned in the Appropedia. This was
> > initially announced as a stand-alone project, the "Universal Production Set"
> > (UPset), see
Bryan Bishop
> Technical basis shall be MediaWiki (since that's the software basis
> of the Appropedia) with the Semantic MediaWiki extension. Currently,
> the project is stalled a bit, while waiting for somebody who can do
> so to install Semantic MediaWiki (and I was, in any case, busy
> elsewhere), but hopefully it will soon be rolling again...
Christian, the openvirgle, SKDB, and OSCOMAK repository guys were
discussing this very same thing about semantic mediawiki a few months
ago:
http://groups.google.com/group/openvirgle/search?group=openvirgle&q=semantic+mediawiki+git&qt_g=Search+this+group
The parallels are exactly the same. The problem with mediawiki is that a
wiki is a revision control system built on top of a mysql database and
php. Revision control systems have long existed before wikis. There's
no reason not to use git, cvs, svn, monotone, etc. If you truly desire
a wiki interface, then you can then go deploy ikiwiki around it to
satisfy the web peoples.
Let's take a few steps forward instead of backwards. Wikis are nice, but
they are nonoptimal especially because of the inherent problems in web
browsing. Maybe if Ted Nelson's Xanadu had taken off instead of HTTP,
then perhaps it would be the place to put these things, but as it is
now, there are other things that should be done, like keeping direct
files, and working with those, instead of forcing me to write crawlers
to download your silly MySQL database through the HTTP interface to
mediawiki with tons of overhead HTML overhead etc. etc. There are other
issues that I brought up in the openvirgle discussions, and again the
discussions paralleled this *precisely*. Somebody (Paul Fernhout) was
using semantic mediawiki, and so we began talking and we came to a
mutual understanding about these things and the (actual) technical
infrastructure we'd be needing for some of this.
I know I sound vague here. Sorry. It's been a long day (Maker Faire) and
my internet connectivity has been gone since last Thursday, so I'm
doing a marathon of emailing at the moment. :-)
> Feedback is welcome, especially on the template -- what else should
> be included, which fields are unnecessary?
Template? Meh.
- Bryan
512 203 0507