Update 07/06/2011:

HexBright has setup a wiki on their website.  Not much content posted yet, but the structure that is in place looks good.  Looking forward to licensing information and documentation.

Update 06/09/2011:

Just got this very clarifying tweet from @Hexbright:

We are going to release mechanical drawings, electrical drawings, and source code for the Flex!! That’s what we mean by open source!

That is very exciting news!!!  It turns out that google linked to much older comments and the team over at Hexbright decided to open everything up on June 2.  Thanks to Hexbright for clearing this up.  I can’t wait to get one of my own (and see the plans).

“World’s first open source flashlight?” This headline caught my eye the other day. As a supporter of relatively new Open Source Hardware (OSWH) movement, I thought to myself, now here is an interesting idea for an OSHW project. I can’t wait to see what type of flashlight it is and what the plans look like. After all, a flashlight is clearly hardware, so surely the developer is talking about opening the entire design… Boy was I in for a surprise.

Before I even read the article, I followed the link to the project website, which is really nothing more than an advertisement for the Kickstarter page. Despite the very clear language indicating the HexBright is open source (“Hex Bright: Open Source Light”), there are no links to a project page of any kind. No information on where to get any plans, source code, or documentation. There is just an email address and the previously mentioned link to the Kickstarter page. Contrast this with open source software projects such as the Python programming language, which prominently links to the source code, documentation, and forums in the sidebar on the project homepage.

Needless to say, this was not an auspicious start as far as I was concerned. Still, I was determined to see what the story was, so off I went to the Kickstarter page. Here you will find a number of videos showing off the HexBright (including one with Grant Imahara of the Mythbusters), but still no links to the plans, source code, or documentation one should expect of a project that is advertising itself as open source. So, I dug still deeper, and googled for “hexbright plans” and found this discussion page on the Kickstarter site. If you scroll down to the bottom of the page, you will find a question posted by user mitpatterson, “Any plans to release the schematic for the electronics inside at all? …”, to which Christian Carlberg (one of the developers) responds:

I just plan on releasing the source code for you light hackers to play with. It’s a good question, but part of what makes the HexBright special is the body shape which I want to keep hold of.

So, it turns out that this is not an OSHW project at all. It is an LED flashlight for which the developers plan to release the source code for the embedded processor that runs the LED.

There are two important points for supporters of OSHW to consider from this story. The first is the need to come up with a common language to describe the relative openness of hardware projects. I think it is important for the maker community to avoid misunderstandings about what is being shared, what will be shared, and what will not be shared (and under what terms does the sharing take place) when it comes to hardware projects. These kinds of misunderstandings can at best lead to frustration (such as I felt while researching the HexBright) and at worst can lead to intellectual property violations (such as someone misusing a design or source code because of a failure to understand their rights to that information). This will likely involve both educating the maker community about how open source can be applied to hardware, and having a dialog about how to clearly label projects.

The second point is that something is not open source just because you say it is. There are clear definitions for both software and hardware, and in both cases being open source requires that the appropriate material (source code and accompanying instructions in the case of software, and drawings, instructions, etc in the case of hardware) be available to the users. Planning to release this material is not the same thing… At all. It is just plain unfair (and untrue) to label something as open source when there are no aspects of the project that are available to end users (and covered under a valid open source license). Again, this is likely something that needs to be addressed through education in the maker community. Though, to be perfectly fair, this is occasionally a problem even in organizations that should know better.

So, tell me what you think. Am I being too harsh or do we really need to address these issues? And is educating the maker community about open source the right path forward? If so, what does that look like? If not, what do you think is the right path is?

ad astra per civitas