The OHR and similar innitiatives represent an opportunity to innovate not only in technology but also in buisness models.
We belong that to an Open SME, we agree that when we address a design we concern about how to get the design effort cover (and if possible even making profit of it). There is a need to innovate on buisness models related with Open Hardware, some innovations are specificly related to hardware, since we have fabrication costs, tooling costs, etc.
Not only the design, but also the fabrication and test of a new product requires and initial investment. The test suits, visual inspection and other quality tests may provide products of very different quality.
We say that we share "cooking receipts" but the quality of the final product may highly depend on other factors such as "quality of components" and "cooking skills...
Furthermore, companies related with specific products and technologies are the best candidates to be involved in future projects related to this technologies....
The OHR and other initiatives are still at early development stages but provide a great opportunity to Technology based SMEs (see some related to OHR at http://www.ohwr.org/companies ). As you can see they belong to different countries and are SME...
We belong to one of them, and we have had several interesting discussions with large companies on the support and reliability model. Even being a Small company and relatively young we claim that even if we dissapear "others will take our designs being able to provide them and support them". Thus, if there is a certain number of companies in the pool, small companies can take rather critical designs. Even if they dissapear, making the designs open shall give trust to potential subcontractors since when a design is open it allows to be reviewed by third parties and allows support not only from the original designers but also from the related community.
boblespam wrote: So I develop during 9 month a nice piece of HW that works. I put it on the open repository because you say it's cool.
Another guy takes the project, eventually make it better if he has nothing better to do that day (the stuff works, so why bother?)
He sells it, I sell it. His product is cheaper because he doesn't have to pay for the 9 month I worked on it. Who will pay the food I ate during those 9 months? Mummy? The CERN? (mostly financed by publics funds)
What you say is possible. But a number of alternatives are also possible:
1. By using OSH, you were able to cut your design time in half, making it possible to hit a market window that would have been impossible on your own.
2. You don't have to publish your design until it ships. At that point, your potential competitor may decide it's not worth trying to catch up. First, there's a lot of time and expense to getting a product shipped after completing the design, such as lining up manufacturing and getting certifications. Raspberry Pi's Gert van Loo gave a talk at the 2013 Design West about the trials and tribulations of getting Gertboard manufactured, called "Designing is Easy, Production is a Nightmare". Second, your competitor may realize that a third competitor could easily step in and drink both your milkshakes, so the Nightmare is likely not worth it.
3. OTOH, you are better off publishing your design before shipping to catch errors that may have slipped in. My favorite recent example of this is the Raspberry Pi, which published its schematics after shipping rev 1.0. An enthusiast at element14 quickly discovered that two 1.8V regions with separate voltage regulators were accidently shorted together, which caused the voltage regulators to compete. This caused a component on some boards to overheat, even though other boards were just fine. If RasPi had released the schematics earlier, the problem may have been found and fixed before production.
However, this is a trade-off with #2.
4. While your design "works", I've yet to meet a design that could not be improved. If you OSH your design, you open it to design review from potentially thousands of eyeballs who may find some substantial improvements, which then trigger your own ideas for further improvement. Humans have a nasty tendency to "fall in love with a solution" and at that point fail to look for better solutions.
I love your idea of having public funds pay for OSH. That would IMO be much more effective at "promoting the Progress of Science and Useful Arts" than the current scheme. Public funds pay for roads, bridges, tunnels, and public transportation. OSH is another way to get from Point A to Point B, so why not?
So I develop during 9 month a nice piece of HW that works. I put it on the open repository because you say it's cool.
Another guy takes the project, eventually make it better if he has nothing better to do that day (the stuff works, so why bother ?).
He sells it, I sell it. His product is cheaper because he doesn't have to pay for the 9 month I worked on it.Who will pay the food I ate during those 9 month ? Mummy ? The CERN ? (mostly financed by publics funds)
@Rick: "I suspect if open development can set a faster pace to market and/or a lower cost of development it will become a de facto approach"
We can say that this is already a de facto approach, but under current development.
If you try to earn your money by only selling hardware products, you are going to get into troubles, no matter how big you are: the profit ratio is diminishing as software solutions gets standardized -- Android, Linux, RTOS...
But if you want to make profit from selling your services and hardware is just a piece of the full puzzle, you can get a lot of advantages by using an open hardware solution. This is the case for services providers such as Facebook, Intel or even Goldman-Sachs, who have joined efforts with many others in the Open Compute Project: having a open-hardware infrastructure in the data center allows for lower prices as it push the competition -- just wait for all those ARM powered servers that are going to be released in 2014 ;-)
@bobdvb: "get first mover advantage and possibly a piece of the other guys pie"
Yes, this is where the real point is. If you want to have a future in the Open-HW/SW world, you must embrace the task of being always a step ahead from your competitors -- in both knowledge and quality!!
@Max: "the term "gateware" refers to the data that describes the configuration of an FPGA or similar programmable logic device"
Yes, thank you very much for pointing to that issue. We can say that the gateware is all those design files describing a boolean hardware by means of a Hardware Description Languaje -- VHDL, Verilog...
Gateware is a fuzzy world where you have some properties from the SW and HW realms. i.e., an IP-Core written in VHDL can be used to produce a bitstream, being part of a "software program" for a specific FPGA device, or also to generate an integrated circuit, which clearly is a piece of "silicon/metal/others hardware".
This issue makes developing an Open License for HDL a very difficult task. I can anticipate that CERN-OHL group has started to work in adapting its license for this purpose -- I'll post about this in a few weeks ;-)
There are as many approaches to Open design licensing as different opportunities exist in the market...
As you say, for a huge company that is able to fully develop its own products from the ground-up, there is not a clear advantage on disclosing any information to the public domain.
But you can build a huge profitable company too by offering services related to open hardware products, just in the same way Red-Hat and others have worked in the software market.
And mostly, open hardware/software is cool for those companies that are not big enough for mantaining a full electronic R&D team: they can reuse well proven open HW/SW components while protecting its own valuable intellectual property.
I suspect if open development can set a faster pace to market and/or a lower cost of development it will become a de facto approach. People will have to adopt it or be left with products that are too late or too costly.
But is this speed/cost advantage the case in real practice?
What are the engineering and design challenges in creating successful IoT devices? These devices are usually small, resource-constrained electronics designed to sense, collect, send, and/or interpret data. Some of the devices need to be smart enough to act upon data in real time, 24/7. Are the design challenges the same as with embedded systems, but with a little developer- and IT-skills added in? What do engineers need to know? Rick Merritt talks with two experts about the tools and best options for designing IoT devices in 2016. Specifically the guests will discuss sensors, security, and lessons from IoT deployments.