Hardware and software are certainly different beasts. Software is really just information, and the storing, modification, duplication, and transmission of information is essentially free. Hardware is expensive, or so we think, because it’s made out of physical stuff which is costly to ship or copy. So when we talk about open-source software (OSS) or open-source hardware (OSHW), we’re talking about different things — OSS is itself the end product, while OSHW is just the information to fabricate the end product, or have it fabricated.
The fabrication step makes OSHW essentially different from OSS, at least for now, but I think there’s something even more fundamentally different between the current state of OSHW and OSS: the pull request and the community. The success or failure of an OSS project depends on the community of people developing it, and for smaller projects that can hinge on the ease of a motivated individual digging in and contributing. This is the main virtue of OSS in my opinion: open-source software is most interesting when people are reading and writing that source.
With pure information, it’s essentially free to copy, modify, and push your changes upstream so that others can benefit. The open hardware world is just finding its feet in this respect, but that’s changing as we speak, and I have great hopes. Costs of fabrication are falling all around, open and useful tools are being actively developed to facilitate interchange of the design information. I think there are lessons that OSHW can learn from the OSS community’s pull-request culture, and that will help push the hardware hacker’s art forward.
What would it take to get you to build someone else’s OSHW project, improve on it, and contribute back? That’s a question worth a thoughtful deep dive.
The Patch and the Pull Request
Back in the early days of what we now think of as open-source software, there was the patch. Indeed, the UNIX utilities diff and patch are probably the unsung heroes of the OSS movement. They enabled a programmer to easily figure out the difference between two (source code) files and pass those changes on to someone else.
Then along came Linux, which started off as a pet project of Linus Torvalds’, but grew to include so many contributors that handling the patch requests became a full-time job for Linus, and then for his “lieutenants” as he subdivided the responsibilities. When Linus needed a version control system for the Linux codebase, he wrote his own: git. No surprise, it was based on the idea of recording and handling incremental patches, but in a distributed manner that gave his lieutenants (but also anyone in the community) the autonomy they wanted to work on the code and then ask Linus to pull their changes in when ready.
It’s easy enough to set up your own web-facing git repository to share your code with the world, but just as more people use e-mail or web-hosting services rather than rolling their own, it’s a lot easier to use a service for small projects. Add in a social-networking overlay to a public git repository, and you’ve got GitHub, the de facto means of sharing and working on OSS information. With a Wiki for community documentation helping you along the way, it’s all downright comfortable to tweak OSS these days.
TL;DR: the heart and soul of OSS these days is pointing your browser at a website, copying the code, using it and improving it, and asking to get your improvements pulled back into the project the same way you got it in the first place. Easy-peasy.
Costly Fabrication
What would the pull-request cycle look like in the OSHW world? I download your design, look over the bill of materials (BOM), and decide to get a PCB manufactured and parts ordered. It arrives, and I play with it. Maybe I make modifications on the board itself or maybe, assuming that I can open up your design files, I make some modifications and order yet another version with my changes. If my changes work, I’ll submit a pull request back to you. Do you verify my changes by producing another one of your things? You can see where the friction introduced to the system by the need for fabrication raises its ugly head, two or three times: at least once for the changed version and once to verify that the change doesn’t break the original project. That’s something we need to work on.
On one hand, small-scale manufacturing has never been easier or cheaper. Gone are the days of spending hundreds on prototype PCBs; there are sources everywhere that will get the job done so inexpensively that many otherwise respectable hackers don’t even consider producing a one-off board at home. Of course the home PCB fab has also never been cheaper, with CNC mills capable of routing a board coming in around $200, or the relative ease of getting good results at home even with toner transfer. Add to this the secret weapon of a well specified BOM, maybe even one that can be ordered with one click or CSV upload, and the frictions here can be minimized. So far, so good. At least it’s plausible that I could replicate your masterwork.
If the fabrication costs are around $20 and a half-hour of time, I could maybe expect you, the diligent project maintainer, to approve one pull request per week, or maybe only if the patch improves the project enough to warrant a rebuild. But what if you ran three or five such successful projects? And it gets worse as a project scales up, of course. I wouldn’t expect a project owner to spin up a board with a $150 BOM cost just to verify my tweaks to the audio output section.
For yourself and any potential contributors to the project, it’s probably worth thinking about making the design as inexpensive and non-time-consuming to fabricate as possible. If you want pull requests, you’ll be looping through fabrication more than once, so extra time here pays off. But with the capabilities of DIY and small-scale fabrication ever increasing, and the price of professional work dropping, the fabrication step is becoming less and less of a barrier, at least for small projects.
Design for Modification
What about big projects that are simply too intricate to replicate more than once or twice per user? Is there any hope for the pull request in ambitious OSHW projects?
If you look at the RepRap project as a whole, it certainly has resulted in the very rapid, distributed development of open-source 3D printers, but you might not expect downstream changes to percolate upwards very rapidly. After all, building any printer from scratch costs $300 to $600 or more, takes hours of time, and isn’t a task that someone’s going to undertake just to check out your pull request.
But still, some of the most successful printers have a good degree of visible community contribution: the old Prusa Mendel has 30 pull requests, and the current Prusa 3 design scores 44. [Nophead], the designer of Mendel90, the other early square cartesian bot, was initially very reluctant to take community help. Interestingly, since he opened his project up on GitHub, he’s received 38 pull requests, and incorporated 35 of them. Success!
How can this be? First, these printer designs are entirely open, written in the parametric, and very easy to tweak OpenSCAD language. OpenSCAD is itself free, as well. So anyone with a 3D printer who wants to try out a modification has a very low barrier to entry. And a 3D printer is also eminently modifiable and tweakable. Many of the sub-assemblies are entirely modular and can be swapped out at minimal cost. You don’t have to build a whole new printer to test out various new hot-end mount designs, and neither do [Jo Prusa] or [Nophead] when they accept your patch.
Incremental changes are easiest to make when you only need to change one section, and not the global design. Modular design, with well-defined sub-units whenever possible, encourages improvement. (Am I talking about object-oriented coding or parts placement that locates the power supply off in a corner on its own on the PCB?) Can you use off-the-shelf breakout modules that are sourceable on the cheap that can be unplugged and reused in the next revision? Maybe you should.
Open-Source Tools
Releasing your design files to the world doesn’t mean anything if others can’t dig in and help you improve them, and that means that they have the tools to do the job. With code, all that’s really required is a text editor and maybe a compiler. With hardware, the “code” — the design files — are often wrapped up in proprietary tools, which instantly limits the audience of potential contributors.
The obvious choice here is KiCad, which is open source and runs on everything. Of course, there’s still the learning curve that accompanies any package that’s not the one you’re used to, but until the entire industry settles on a compatible file format for schematic capture and PCB layout, you might as well choose the most open, widely available, and least encumbered tool.
Eagle, which has had an XML export format since Version 6 in 2012, is another contender. The tool is free to use for small boards, and it has a large number of users. We know how to get files out of Eagle’s format very well these days, including exporting entire part libraries, which means that KiCad users can hack on your files. I don’t know if it’s possible to make the round trip, though; can one import KiCad files back into Eagle?
There are many other tools, ranging in price from free to professional-use-only. For this article, I don’t care at all about their relative ease of use — if a large chunk of your target audience can’t use it, or if the file format doesn’t lend itself well to differences and revision tracking, you’re shutting out potential pull requests.
The Fine Art of the README
If there’s something else we can learn from the OSS world, it’s how important good and inviting documentation is to the success of a project, both for the end-user and for the potential hacker. And perhaps the first lesson here is that the distinction between end-user and hacker isn’t that great.
The potential hacker will also be more likely to try your project out in the first place if it’s easy and appealing to make, just like the end-user. 77.23% of all statistics are made-up, but I’d bet that the overwhelming majority of folks contributing to OSS projects are satisfied, or maybe even slightly disgruntled, users of the software in question. So show potential builders how to build and use your project, but don’t forget to show potential hackers how it works and how they can get inside it. And if you want to accept pull requests, don’t forget to say so, out loud.
Feedback?
Can we build a pull-request culture in OSHW? I hope so, because that’s the best part of OSS, but I’m also realistic. The raw physicality of the real world will always get in the way to some extent, but the pure cost barrier of replication is shrinking year on year. After that, it’s a simple matter of software, and getting everyone to use interoperable design tools. Yeah, that’s hard.
So in the mean time, what can you do to make your OSHW project more appealing for other hackers to contribute to? If the costs, both in labor and money, of replication are as low as possible, someone might make it. If they make it, how likely are they to improve it? That depends on how modifiable and modular the design is.
If you’re using non-free software for the design, can the data at least be exported? Or can the user work around your inflexibility by simply exporting the design to the tool of their choice? Finally, how well documented and inviting is your project for potential contributors, not just in use, but also in modification? Do you say you encourage pull requests?
Anyway, there’s some brainstorming about how we could make large-scale community OSHW work. Naturally, I’d love to hear your take, and examples of any successful projects with contributions from the public, in the comments. What else?
Some open source already out.. Didn’t Chevy build a car with a Toyota engine?
Maybe not exactly open source..
The Pontiac Vibe was basically a Toyota Matrix. There may be other examples, too.
Also, I want to say I saw a project years ago where a Toyota 2JZ motor dropped directly into a Pontiac Solstice. Motor mounts lined up and the transmission bolt pattern were the same.
It’s been said, (tongue in cheek) Toyota + Chevrolet = ToyLet
+1
I used to have a Chevy Prism. It was the same thing as a Toyota Corolla and I often took parts off of Corollas in the junkyard to keep mine going. They were built as a collaboration in the same factory out in California. The same lines with the same machines and the same tooling would literally be stamping out Chevy parts one day and Toyota ones the next. All that changed was the nameplate. Unless it was an internal part… then it just always said Toyota on it.
Oh, yah, but what does this have to do with Open Source Hardware? These cars existed as collaborations between exactly two companies with limitations no doubt written in specific detail by expensive lawyers. They certainly weren’t inviting Chrysler, Honda and everyone else to the party to share in their designs!
People digressed.
Toyota and GM shared a plant in California (later bought by Tesla), some of their collaboration was probably more making it easier to share those production lines, seriously doubt if its anywhere near opensource .
OK as I learnt all this from my stepdad who dealt in re-manufactured engines, the badge on the car doesn’t mean the chassis engine or any part of it was designed by them, basically it’s expensive to get things especially chassis’ through the testing required, so a lot will just slap on their own body, engines are the same, it’s not practical to design an engine for every type of car you have so you use someone else’s and in turn they might use yours, no lawyers crunching out the details, just straight up business of I would like x of these (lawyers are probably involved somewhere, you just can’t get rid of em lol) so no it’s nothing like open source
Apples to oranges. Mixing thing ups within an international corporate infrastructure isn’t likely to get lawyers involve. However if a company A makes note that the public likes an engine company B produces, and company A manufactures copy it and uses it their vehicle, lawyers will be involved.
That’s more parts sharing and rebadging and it’s fairly common.
Mazda used a Ford V6 engine in some SUVs and trucks in exchange for providing Ford with a small i4 used in some FWD cars and Chrysler often used engines from Mitsubishi.
Now something automotive that can be considered open source I think the original small block and big block Chevy V8 engines are pretty much public domain designs now since you can build one using nothing but third party parts.
Alas, CPUs are left out of this path, with a few – almost useless – exceptions (such ad FPGA implementations, discrete implementations, etc.)
SiFive makes an fully integrated Risc V CPU that is open source. Though I couldn’t get them to release the gate-level netlist, so not open enough for me.
Hardware always has been open source, you just need a socket set, an osiliscope and some intuition!
Software always has been open source, you just need a assembly level debugger, a binary-patcher and some intuition!
+1
Open Source is a little different to Reverse Engineering. Open Source is (supposed) to provide more than just a ‘user manual’, and in code at least, one would expect comments to explain the purpose of doing something.
Hardware is a bit clearer as to what/why something has been done, but was there a reason that I2C was used rather than SPI? Was it just the designers experience/familiarity, or was there actually a tecnical reason?
The name itself, OSHW – Open Source HardWare – tells a lot which I think the author has missed. It is about having access to the SOURCE of the design, and does not neccesarily mean it is going to be like an OSS project with lots of contributors. Perhaps the sole intent of releasing an OSHW project is to future proof the design? When dealing with older hardware, the want to tweak some aspect of the design because a chip is now obsolete but the ‘thing’ is something worth keeping (or doing a re-run) is pretty high. With OSHW I can do that. With propretry hardware, it is a LOT harder. And yes, I’ve done both.
The author did not miss the meaning of Open Source HardWare – he was highlighting one of the non-technical special qualities of popular Open Source Software that drives improvement and suggested ways OSHW projects could change to nudge users into becoming contributors. Should we keep repeating the argument that hardware is too expensive to fabricate to have a vibrant community of contributions and testing, or should we look to behavioral sciences to suggest minor things that projects could do differently to encourage a community to grow up around a project?
I have published code on github, so technically I’m a FOSS publisher. I have never had a community of contributors help program my blinky lights. Not everyone wants that kind of help (Arduino), but for those who aspire to have help and community, these are fantastic insights.
@Fred. I didn’t miss it — I just think that the shallow definition of open source is not where we want to set our sights. Open source is a means. The end is cooperative development so that everyone gains with the minimum global effort.
“Here’s the schematic of the thing we made” is shallow. “Hey, we want you all to take part and make this thing significantly better, oh and here’s the schematic to help you do so” is deeper.
How do you make a difference between “cooperative development” and “design by committee”?
Often in hardware as in software, the guiding vision of the original maker is just as important as the contributions, because that’s what keeps the whole thing goal-oriented instead of just flying apart at the seams with featuritis and poor compromizes to include everyone’s contributions.
For example, the way software works can easily be modular because there’s little penalty for added complexity, but in hardware, integration can be paramount such that you don’t end up with components that work in their own right, but are nevertheless poorly suited for the ultimate task they’re supposed to accomplish.
Like for example, I was part of a task group to design road maintenance equipment, where one group was designing a tractor and other groups the implements it was supposed to pull. The tractor group got their work done, the implement groups got their work done, and it turned out you had to put a ton of pointless steel weights on the front of the tractor to keep it from tipping over. Back to the drawing board.
Why? Because this division of labor forced the choice on how the implements attach to the tractor to minimize the need for inter-group communication for integration. Because there were so many different groups working on the same problem, to speed up the work they first had to strike down the design of the interfaces without even knowing what the whole product is going to look like, and that insistence of co-operation between multiple parties ultimately made the thing unbalanced.
If there’s three people working on the same schematic, they have to establish rules so they don’t mess up each other’s work, and those rules end up constricting what they can design. This is why hardware can’t be open source in the same way as software can – at best it can be “here’s the finished schematic, now what would you do differently?”
What I mean is, in software, you can agree to pass data between functions in certain formats, and if you later choose to change the format it’s not such a big deal because the part that does the data parsing is different from the part that does the algorithm.
But in hardware design, if you choose that power is being delivered by hydraulic hoses, and then change your mind to say “no I want V-belts instead”, the whole thing goes to scrap because now you have to re-design the chassis to place your pulleys, move the steering column out of the way, think of where the access hatches are supposed to be… etc. etc. everything changes everything.
In hardware design, you may work under the assumption that some signal is coming in PWM, and design your circuit around that – and then someone else says “you know what, le’ts make it a 4-20 mA current signal”, and you go “fffffff.f……”
Luke – the questions you bring up regarding integration has already been solved in Extreme Manufacturing (https://en.wikipedia.org/wiki/EXtreme_Manufacturing) by what is known as Contract-First Design. It is part of a modular design method where interfaces between modules are defined prior to designing the modules themselves. This is a critical enabling breakthrough for modular open hardware design. You can read more at http://opensourceecology.org/wiki/Contract-First_Design
The references to extreme manufacturing and contract-first design seem like a variation on Axiomatic Product Development Lifecycle which is meant to achieve similar goals: https://en.wikipedia.org/wiki/Axiomatic_product_development_lifecycle
Perhaps the most well-known open source hardware is Arduino. They publish all the design data for their boards, down to the Gerber files.
Yet, the cheap Chinese clones that flood Ebay don’t use that data; they re-spin the boards to use their favorite USB chips, connectors, and other components. The only open-source stuff those clones use is the software: the bootloader that resides in the Atmel chip.
The public Arduino hardware data is useful only as a concept, and it wouldn’t be hard to extract without permission from the owner.
I actually left Arduino out on purpose.
They _do not_ solicit feedback from the community on their hardware. They are open in the sense that you can see their designs, but not open in the sense that the hardware is a community project. They make what they make, and you can take it or leave it.
Elliot: Arduino makes hardware because they have to pay their bills, not because they want to contribute with the community. This is precisely why they openly distribute EAGLE files of their hardware… to allow others to do what they don’t. I do not see them as a “not-open-hardware” company, I see them as THE open hardware design distributors.
I’m surprised the Chinese have not cloned Atmel chips as well as copying even more complex things such as older Intel chips such as anything pre Haswell should be within their technical ability.
The Soviets managed clone the several Intel chips up to the 80386 back in the 1980s.
Copying other people is like building a palace on jacklifts. It’s not a stable foundation.
Point in case:
https://www.washingtonpost.com/news/worldviews/wp/2017/01/18/finally-china-manufactures-a-ballpoint-pen-all-by-itself
“Manufacturing a ballpoint pen tip that can write comfortably for a long period of time requires high-precision machinery and precisely thin steel, but for years China was unable to match those crafted by foreign companies.
While there were over 3,000 companies manufacturing pens in China, none had their own high-end technology for the tip.”
Point being that in China, developing a clone of a thing like an Atmel MCU requires R&D investments, which none of the companies are willing to spend because there’s no immediate benefit to the company, and a domestic clone would be immediately copied by other Chinese companies.
The point of making these chips for the Chinese is not to use them, but to sell them, and that they’re already doing with western companies commissioning factories in China. Should they start making them, entering into competition, they’d simply be competing with themselves.
Hardware is not software, but sometimes they share common resources…
1. The primary reason FOSS works is because the production cost of replication is near $0.00/pc.
2. Hardware costs money, and people have to reallocate it from other spending habits to even participate.
3. Hardware value only reaches consumer expectations with high volume, but there are cottage industries who choose to gamble on what people might want — and fracture the markets. However, new participants usually do not want to bear the cost of design, testing, and failures. Socializing build costs simply doesn’t work, as there are too many people who don’t feel obligated to the original work unless the product name helps sell clones.
4. Building open hardware is not sustainable for the authors, as consumer behavior shows only established manufactures can ultimately benefit from popular works. Factories only care that the machines keep running, and don’t care who they con to make revenue. Ask any of the countless people that see their unmodified work for resale on the auction sites, as entire businesses have sprung up to fill the void created by faulty design contention (Sparkfun/Adafruit).
5. Modern pirates clone everything, contribute nothing, and ultimately destroy the markets they enter. There really isn’t a community of progress anymore, but rather a ecosystem of poorly designed hardware makers trying to leverage someone’s ignorance. In my opinion, 3D printing hardware development has stagnated for years, as the market saturated with low end products with high failure rates — and no sane person wants to invest their time and money to see some loser try to monetize their work though social media. Keep in mind these people with working 3D printers should in theory be evolving their own designs… at least thats what the loud crowd wants you to believe for unknown reasons.
6. Socialism doesn’t work, as it only encourages corruption of its participants — and ultimately degradation of shared physical resources. This fact is not a value judgment, but simply human nature.
https://en.wikipedia.org/wiki/Tragedy_of_the_commons
While I agree with you on many fronts, I still think that open source hardware is better than the alternative. When lazy manufacturers copy someone else’s design, They are unwittingly contributing to the spread of open-source standards. Thus making later repurposing, maintaining, repairing, and ultimately hacking, much easier for the end user. If all hardware were open source, we’d live in a world quite similar to the one now, just with a lot more cheap rip-offs of hardware and many more cool cross-platform projects.
No, when Chinese pirates copy someone else’s design they hurt the original manufacturer and give him a bad name. In addition the copy put out by the pirates tend to be junk not worth repairing or even using in some cases. Like the fake USB FTDI chips you hackers whined about,
And when the company tried to defend it’s IP, you open source moochers went nuts and blamed them instead of the Chinese pirates. No one told you to buy cheap knock-offs from pirates but you did.
Also open hardware de-incentivizes people from designing and manufacturing new products because they know within a few months some Chinese company will rip them off and flood the market with knock-offs. Mind you they do it anyway, but open hardware givens them a road map.
I have zero sympathy for FTDI. Why? Because the USB standard includes a definition for a serial adapter. If manufacturers would follow that we wouldn’t need their drivers. Instead they all (including FTDI) have to be unique and go their own way. Why do we need to install drivers for something so basic? It’s ridiculous. Likewise if I wanted a peripheral to work with some super obscure (probably OSS) hobbyist OS… the best chance of that working would be if manufacturers actually followed standards instead of writing their own!
If manufacturers would use the standard, they’d just be making a standardized product – one that everyone else can make from a reference design with no more and no less functionality, and where’s the money in that?
The point of HW drivers is lost there – a hardware driver is supposed to be a means of third parties to plug in to your system. The interface you’re responsible for as a developer is between the OS and the driver, and the interface between the driver and the hardware is the third party’s responsibility. The best chance of your obscure OS working with some obscure device is if you provide a standard interface for the drivers instead of demanding that the manufacturers design their hardware for the drivers you choose to work with!
We can’t have the improvenent of a product without competition. Reverse engineering is (or should be) a legal way to copy another company’s product. One also gets what one payed for, My FakeTDI outputs 4v instead of 3.5v. It only cost $5 online. I’m fine with its flaws as I don’t currently need a fancy usb to serial converter. If I needed a fancy USB to serial converter, I’d buy one from a more quality source. I definitely don’t want to buy products that break other things intentionally.
@zerg
“when the company tried to defend it’s IP” ???
Perhaps you should try actually reading the relevant articles instead of just looking at the titles.
There’s a very, very big difference between defending their IP and deliberately disabling other people’s property in a ‘hissy fit’ as our American cousins would put it.
Considering the number of UK, EU and US laws they broke in the process, they were lucky not to face criminal charges over it.
Yeah, we should worship “engineers”. Their designs are the gospel.
If your business model relies on someone not copying your design (which is easily copied in many cases), then you don’t really provide any value. Your design itself was based upon decades of other people’s work.
Software is about selling service, not source code.
Maybe learn to monetize your work better, because they will always be someone who will try to upend you.
If you bankrupt because someone makes videos on social media XD
try to reconsider your business operations.
If I want to buy a cheaper alternative with worse paremeters, who are you to forbid that?
If a cheaper alternative is viable, it means your product is not much worth in the first place.
I am not seeing apple phones being copied, despite it being very possible. People are not buying them, because they recognize the quality.
The whole thing in this discussion is “talent” isn’t cheap, nor easily reproducible.
you have hit the nail on the head.
Oh the irony…. Linking to wikkipedia to illustrate the tragedy of the commons.
Not really, wikipedia is FOSS software — and thus consistent with point #1.
Still, your straw-man argument is funnier than the OSH article.
=)
Ha! Mudslinging!
Calling people out on their logical fallacy in and of itself is a logical fallacy.
Making logical fallacies does not prove an argument valid.
(See what I did there!)
Basing an argument on calling out a logical fallacy is a fallacy. The fallacy wasn’t his counterpoint, Wikipedia being software was his counterpoint. So no fallacy-fallacy to be had
The tragedy of the commons applies (if at all) when there is a limited resource to be shared, and no communal voice. This is not the case with IP, Me sharing an idea with you does not mean I am left with less of an idea. Knowledge is different to any other resource, especially in the digital age where it copies flawlessly, and often translates directly to a product. As we move to greater and greater one off production automation we move hardware closer and closer to being treated as IP.
True hardware does costs money, but there are many examples of open source hardware projects that do work, the best known in these circles is the arduino. Sure there are clones, for a fraction of the price, but from hoping to sell 50, arduino sold hundreds of thousands. And this despite costing up to 6 times to cost of the clones, largely because of the goodwill and participation that is so often associated with open source projects. The 3d printer market is another, my friend has a closed source printer, purchaser cost : 50 times that of a Prusa i3 clone. His filament also costs about 50 times as much with DRM protection. It just sits there, too expensive to use. Joe Prusa in the meantime has the kind of PR money can’t buy. His units cost more than the clones, but his sales are still huge.
The tragedy of the commons doesn’t depend on having a communal voice. It’s about the costs being shared while the benefit is private, where increasing consumption is always going to increase your personal benefit even as it dwindles the common resource. Even with a common voice, people may say “Look, our commons are being destroyed, we must stop over-using them!”, and the other people go “Okay. You first.”
It can be anything, like slacking off at work, or using the products of Open Source development without contributing back yourself. People may point out “If we all contribute, we would get it faster and better”, to which other people say, “Okay. You go first.”
About #5 . When I decided to get a 3d printer I talked with a friend who has a flashforge and did a bunch of research into other ones before just going with one of the clones because I like to tinker, when my brother was looking at getting one for his kids we talked about different aspects of the machines and he went with one of the big names for the support they offered and a good warranty. I belong to several forums for these cheap clone printers and there are lots of people that after realizing they enjoy 3d printing spend the $ for a second machine from Prusa Research, Makerbot, Lulzbot and the like that they probably wouldn’t have bought if they hadn’t had an entry level machine to try first. I own a bunch of duino clones but I also own some of the official ones to support the ecosystem, I own more of the teensy’s from PJRC then I have real uses for just to give some support and to have available if a project needs that extra bit. I have bought 5 raspberry pi’s over the years (gave 3 out to kids with some instruction) but I mostly use orange pi’s in my projects and have gone through about 15 of them. The “modern pirates” don’t really do as much harm as you make them sound, did you get burned because you expected the quality of an original Prusa from a $150 kit?
While I am amused by rhetoric of all flavors, my personal feelings on what you chose to purchase are irrelevant in general.
Much how you expect a seatbelt to function in your car — I expect manufactures be accountable for what they sell irrespective of the designs origin.
Funny your choice of seatbelt as an example since many would argue that Volvos filing of a open patent on the 3 point seat belt would make it a open source hardware design….
Concerning your feeling that manufacturers be accountable for their parts, in my experience they are, I have received a few bad parts in these “kits” and despite it taking 5 pictures, 2 videos, and 7 to 10 email exchanges I have always got replacements for defective parts. On the other hand If I feel that a supplied part isn’t good enough I realize that its my responsibility to make that change to their kit not whine after the fact that they sold me something that wasn’t as advertised when it was. Very seldom when dealing with “clone” parts or kits are you dealing with the manufacturer direct but with a re-seller who you need to investigate to see if they will provide service after the sale.
This approach works fine for a hobbyist, but not for someone who deals with larger scale manufacturing. It is known fairly well that just because your sample tests fine it does not mean the bulk follow-up order will contain parts of equal quality. Unless you are a hobbyist you can not test every part that goes into every assemby. In a lot of cases it is difficult to even test every assembly – you have to rely on statstical sampling.
In *most* cases you get what you pay for, but some cheap items can be legit, and conversly, some expensive items can be fake.
I think you are confusing Socialism with Communism but that’s ok, I don’t care.
What I don’t get is why people insist on conflating open source with economic systems. You are missing a HUGE difference!
Communism, Socialism and Capitalism are all systems for getting the population to do things for the greater good that they otherwise do not want to do. People aren’t going to spend their waking hours toiling in a field just so others can eat. Nobody is going to dig ditches and level land for roads. Nobody will do any of this unless.. they have an external motivation. Maybe it’s a government forcing them, maybe it’s customers giving them cash. Whatever, the point is it’s all about getting people to do stuff they don’t want to be doing.
Open source on the other hand almost always starts with somebody’s hobby. It’s people doing the stuff that they DO want to be doing! I wouldn’t pay a grocery store for food if there were a bunch of people who love cooking so much that they are constantly trying to give food, often better quality food away for free! Likewise if there were roving bands of people that wander around fixing the roads everywhere they go just because it satisfies them you had better believe I would be contacting my local government representative to discuss a tax reduction! None of this makes me a communist, it makes me reasonable!
Open source starts first and foremost with hobbyists. It’s what connects them and in doing so multiplies their ability to make the things they want to make. Don’t worry though, it isn’t about replacing your favorite economic system. For everything that people don’t want to do for free there will always be some mix of Capitalism and Socialism that the deluded people on the left or the right will cling to and claim is the pure Capitalism or Socialism that they either love or love to hate.
+1
Thing is many left-center-right can’t understand that capitalism, communism are all economic models,and yes elements of all three are are present in economies that are working well. IMO when it comes to open this or that,, understand what is or isn’t being cooperative the term should be cooperative is left to those being the judging, if those being gives a rat’s butt about such judging, that being the SOP of those who get things done.
They’re both models and modes. One tries to outline how the economy should/shouldn’t work, and the other is how it actually works.
Usually the two – model and mode – don’t match. For example, communism always devolves into a degenerated worker’s state because the people can’t keep their elected authorities accountable by any practical means – the moment authorites are elected and raised to power, they gain the ability to reward loyalty and punish dissent, and from there it goes straight to state capitalism.
Lenin gave the Soviet people the ownership of the means of production, and Stalin took it back.
>”Communism, Socialism and Capitalism are all systems for getting the population to do things for the greater good that they otherwise do not want to do.”
I disagree on that definition. Communism and socialism are systems for getting the population to do things for the “greater good” as defined by a (self) appointed leadership, a political elite, or by consensus, whereas capitalism is what happens in the absence of such leadership when people do whatever they must to make their means meet their ends. I choose to define capitalism this way because I want to emphasize the point of the mechanism of the flow of capital as the integrating flow of information between the people – capital as a form of common consciousness that emerges from free interaction – distinct from the socialist mode where information is gathered from the bottom up by specialists to the class of people designated to be its “brain” and then pushed back from top down to command the “body” of the society.
Capitalism is a result of the liberalisation of society from the top-down hierarchical structures of the past. Capitalism as a word is actually a slur from the socialist left as opposed to the liberalist left, who criticized the free market economy by claiming that it would necessarily result in the hegemony of the rich, which they equated with the aristocracy, and thereby started claiming an otherwise left-wing ideology of live and let live to be “bourgeoisie” and right wing. It was this socialist-left that then went on to construct another top-down society in the place of the one they deposed, by arguing that they represent “the people”.
The main ideological difference between the liberalist left, or the capitalist, and the socialist left which became the communists, is the notion of society. The capitalist aknowledges that the society is an arbitrary abstract construct and its individuals don’t necessarily have a “common best” in many if not most matters, whereas the socialist/communist argues that there exists an optimum solution for all – one which is discoverable by reason and should be taught to those who are ignorant of it and enforced to those who disagree.
As Hegel would put it, in socialism the function of the individual is to serve the state as an organic part of it. In contrast, capitalism is the social organism that emerges when its parts function for their own ends and find cooperation to be of mutual benefit. It’s kinda like the difference between saying “animals behave in order to survive”, or “animals survive because they behave” in describing evolution. One point of view suggests that society has a direction to follow, where the other says society happens as it may.
This to me is a design challenge. Design for the dude who doesn’t have any of the ‘nice toys’ but has to do it the hard way. There will always be haves and have-nots, as long as capitalism runs things. (@LOL — you’re confusing socialism with communism, BTW — they’re different, particularly in that real socialism hasn’t been tried yet, only communism.)
If you design for the lowest common denominator, tool-wise, you get something *everyone* can build. You then can adapt your processes and instructions for more sophisticated equipment (etc). But start with the bottom and work your way up, rather than the other way around.
Example: look up a dude named William Kamkwambe (I *think* I spelled that right) — the so-called Malawi Windmill Kid. He built a power windmill out of crap, scrap, and banana tree leaves. His first soldering iron was literally a piece of scrap wire and a campfire. Sure, he’s come a long way since — he gives TED Talks now — but if you start roughly where he did (OK, OK, kid with a Radio Shack iron level works fine here) then even he can build it. (If you literally start at that level, you might be able to engineer for a post-apocalyptic scenario — given the current politics in the US and eg North Korea, that might be a *good* thing!)
Remember. There are people who can’t buy a 3d printer or even a timeshare on a laser cutter. There are people who can’t afford power tools, let alone a CNC. I have a power drill and a Dremel. That, and a battery drill I built myself, is the sum total of my power tool selection. Need me to cut something? If it’s metal or plastic, Dremel. If it’s wood or pipe — I got a Stanley FatMax, a couple hacksaws, and a crosscut saw. All of my saws are hand powered. Keep the job small, please!
The trouble is if you build something that can be built by the lowest common denominator chances are nobody can build it efficiently.
It often takes less time to redesign something for the tools you have than it does to use the wrong tools to build it.
I’ve wanted to build a soldering iron out of an old toaster and some wire for a while now.
This “hacking minimalism” is quite the opposite of a “script kiddie” in software. Beginners using cheap or homemade tools to do amazing projects is its own cool aesthetic.
In the developed world I bet there are far more people who THINK they don’t have access to laser cutters and 3d printers than actually do not. I can think of two hackerspaces within a 35 minute drive of my house that have free open to the public days at least weekly where you can just walk in and use their equipment. A third is only a little farther away and if you have at least a little money to spend a fourth plus several libraries are available too.
That being said I am in a crappy midewstern city far from the maker meccas of Silicon Valley and/or NYC.
It seems to me like too many people want to have the whole world within a 5 minute walk of their studio apartments.
A 5 minute walk?
Don’t be silly. The ‘ooh shiny’ generation won’t do that. What they will do is whine incessantly about not having access to whatever it is they need unless it’s delivered right to their hand within minutes of them thinking they might need it.
My observation is the complainants you speak complain no more, or no less, than their parents, grandparents, and great grandparents generations.
First the article has nothing to do with space regardless of their prefix, or 3D printers.. I have no doubt you present the fact in your reality with 100% accuracy, but to be be kind as possible you are projecting those fact to disparage others. Chance are pretty good those you spoke of probably don’t have the same access you do. Live in a rural area where many if not most end up retiring to apartments of the size you speak of giving up their shops or crafting spaces. The old hens if they have a care can go to the library to knit or whatever, but the old cocks are SOL.
You mistake access for availability.
Suppose a thousand people came to your hackerspace today to use your laser cutter. How many of them could actually get anything done?
Suppose everyone become baker. Who will grow the wheat?
Statistics is a thing.
The point is that many many more people might be makers if they didn’t have to bodge things up by hacksaw and hot glue. Alright, so the argument goes that actually, all these people -do- have access to free laser cutters and mills and 3D printers that they just don’t know about.
But, if they did know, the hackerspaces which offer these services would be inundated by the number of people, and to expand services they’d have to start charging money.
This is a difficult subject for me. Some years ago, published a microcontroller-based project for measuring junction box/PV interface, and an analog circuit for PID control of a vibration platform – after permission received from employer. There was also some source code. Was originally intended as engineering reference for customers, but the hobbyist community found it; and then a shit-storm ensued.
E-mail and letters demanding technical support from non-customers, threatening phone calls to the sales department, and some kid that arrived on our front door demanding that my employer assist him design/debug his circuit. And have been told similar stories by engineers at other companies that were foolish enough to give back to the community.
“Open-source” hardware is a commercial quagmire best suited for the good peoples at places such as PJRC, Sparkfun, Adafruit, etc. If you want to ‘give back’, best to send the design to these people and let them handle the morbid and dangerous masses.
Wonder how all those people would have dealt with the app-notes in ancient data catalogs?
Poorly I suspect, as that would involve both reading and understanding the material. Something they are almost certainly either unwilling and/or unable to do.
That sucks. I’m sorry it happened to you!
“Commercial quagmire” is exactly right. It’d be cool to see OSHW encompass projects outside maker-companies, but there are just too many business issues. When I’ve considered going this route with a consumer-type product, one nightmare scenario is getting stuck with a warehouse full of inventory because another company made a minor iteration on your OSHW design that the market picked up. Rework is incredibly expensive, even if it were possible.
Software faces almost none of these issues.
I see two ways to be make it in OSHW: 1) Build multiple maker-type projects with minimal investment (like Adafruit etc), so the future of the business is not dependent on a single project, 2) Build a consumer-type product, but deliberately make aspects hard to copy (by tooling, choice of tools), etc. Not exactly in the spirit of OSHW!
Any true OSHW companies with consumer products that has lasted more than a few years?
Kickstarters where one gets their money up front.
With the caveat of running up the costs to the point where you’re not making profit because you can’t up the price after you’ve already promised.
Define “make it”, do you mean as a business? I see people doing small runs of hardware fairly frequently (keyboards, SDRs, hobbyist stuff like that). Unfortunately the hardware is rather expensive compared to mass production, and usually impossible to find after the 1 or 2 runs.
What you’re pushing straight to master?
He is hip with Trunk-Based Development. Are you still using GitFlow?
Regarding design/configuration management, Git branching is an underrated feature for OSHW projects. Branches can be created for various specs, uses, or tooling requirements . Branches can be updated or maintained concurrently or asynchronously as the case may be.
Indeed they can. The problems occurs when you start trying to merge branches. Fortunately there are tools to help manage merge conflicts but it’s still mostly a manual process.
I wonder… do OSS project maintainers like Nophead and Prusa actually build every pull request they accept? I can see how in circuit design that would be necessary but is it really necessary for mechanical design? Or can they just check it out and see how things fit together (or don’t) using their CAD software and make a decision based on that?
I think having to use real resources to build everything someone sends in would put me off of the idea of accepting pull requests very quickly!
Also, there’s always tricks like printing out thin shelled parts with no infill and stuff like that if you only need to see how it fits.
I bet they print it out. It doesn’t take much, and they’ve all gone through so many revisions internally. I’ve probably made on the order of that many tweaks to any of my printers and I’m just a dude.
Prusa and Lulzbot (and probably others I don’t know) have farms of printers, with minor variations on them, running all the time. They are constantly testing out changes, probably more internally than externally.
The big (other) story in 3DP is how there are more forks than contributions upstream — there are 500 “reprap” printer designs. Everyone takes inspiration from each other, without explicit pull requests, all the time, but it’s the same basic idea in a way — copying, improving, passing on the improvements.
We (tigoctm.com) are currently building an open source secure hardware, firmware and software desktop (to start). We are searching the best open source solutions at each level. These machines for the masses will allow people to know how the machine was built, as well as allow people to re-compile and change options for their own use. Hopefully, this will start a new trend in “open”.
What I am surprised is the the “Remixing” model used by people on Thingiverse did not come up. This shifts the need to verify the changes to the person doing the remix, and still allows the originator the option to incorporate the changes (or not) by notifying them when some attributes them as the source.
As a mentor for a FIRST Robotics team, I would be interested in FOSS tools that would help with versioning by remixing (especially consistent naming of parts and sub assemblies) so that forked designs can be folding back into the original more easily.
Very good point about “remixing”. See my comments above about “forking” in the RepRap world too.
The idea of reusing parts and sub-assemblies, though, is part of what I was hoping to get into with the modularity. Once I’ve layed out a linear voltage circuit, why should anyone else ever have to ever again?
Maybe to change some component values, use a different shaped capacitor to fit in a smaller enclosure, re-arrange the components to better fit the rest of their board layout, pull a trace out here instead of there, use a different voltage reference than specificed, add some function, double the outputs instead of doubling the whole circuit… etc.
I mean, the basic circuit might be the same but the implementation can be product specific.
I’ve looked into two OSHW projects, one I built fully and one is still in pieces in a box under my desk.
The one I built didn’t really have much in the way of community or feedback. The BOM was very poor and I made some mistakes along the way. After making the mistakes, I was able to notice little notes scattered about the documentation that addressed my issues, even if I thought the notes were obscure and non-obvious. (The written instructions and the video instructions weren’t exactly the same and were each missing a critical step or two. Combined they were complete, but it took a keen eye to spot the differences and combine the two.) There wasn’t really a way to give feedback and make comments or changes, so I didn’t.
The one in pieces used better open source tools, including having all the files on Github. I made a few suggestions in discussions, but the project creator here no longer seems involved and the community is small. Eventually I ran into a few gaps in the documentation and a few issues with implementing the code on the hardware, leading me to shelve the project. It’s a shame really, but what can you do. I was working on a change list and suggestions, but I’ve shelved that too. Maybe that makes me a bad contributor.
That sounds like the opposite experience on nearly every point in my list! Ugh.
There have actually been several projects on Hackaday.io that have been re-built by the community, with (hardware / firmware) changes pushed upstream.
I certainly wouldn’t expect this article to include a full history of revision control but it kind of makes it sound like git was the first and with it Linus Torvalds invented the whole concept from scratch! I’m not sure if version control started with CVS or if there was something before it (and before my time) I always knew it as a progression of small steps from CVS through SVN and finally to GIT with Mr. Torvalds only being involved in that last step.
Likewise Github was not a brand new thought from nothing but instead stands on the shoulders of Sourceforge. And, while I know that the majority of the community thinks Github is the best thing since sliced bread I would like to offer one minority opinion.
Open Source has never been known for good documentation but it seems to me that even the pretense of wanting to document anything at all pretty much went out the window of ever intending to document anything at all. In the old days every project had to have it’s own webpage. That was a barrier to entry but it did mean that one had to at least try to document something just to get an idea off the ground. Then came Sourceforge. It included not just a Subervsion repository to keep your code but a website as well plus tools to integrate comments, commit history and stats into that page. Most people’s Sourceforge pages still made Geocities look like the pinnacle of design though.
Now the typical project is nothing more than a git repository with a README file. And the README.. it’s usually just a copypasta rehash of the configure; make; make install steps plus maybe some verbage about the license, all too often stating that you are giving your design away for all to use freely out of the kindness of your heart unless.. they ever try to make any money off of it. Somehow it hurts people to think that someone else is making money off of something that they aren’t even trying to make money off of themselves. I don’t get it. My stuff is either commercial for me and me alone to profit from or it’s not and you are perfectly welcome to redistribute it any and every way that you can. I don’t get this in-between crap.
Ok.. I’m rambling now. Goodbye!
Re: GitHub and Git. You’re right. I wanted to condense that part of the article down even further, but it got to the point that I couldn’t take any more out…
I’ve used CVS at work, and was an Subversion fanboy as late as 2010ish (?), when git got really good. (I even gave a talk at work on open-source VCS options back in 2004-5 (?) where I said that git would someday steal the spotlight from DARCS if it kept improving. Remember DARCS?)
SF definitely had its day in the sun. But their integrated webpages were horrible — most serious projects just linked out to their “real” page (and vice-versa) from there. And the fact that my parents could never figure out how to d/l software from them anyway…
But as long as we’re reminiscing, remember Freshmeat? What’s taken the place of the cool-new-software-you-must-try venue?
Last I saw it was still there. Remembering the time when the owner got so pissed off he wanted to quit.
I think he did, didn’t he?
In any case, the whole thing was sold to the SourceForge scammers a couple of years ago, but it had been dead in the water for at least two years prior to that.
I’ve no idea what, if anything, has taken it’s place.
While we’re on the subject of useful sites which have been sucked dry by greedy vermin, does anyone remember the original Tucows?
“does anyone remember the original Tucows?”
I remember it, I don’t recall when it disappeared…
Yes! I remember Tucows!
I doubt many people at all know exactly when Tucows disappeared. Instead we remember when we first switched to a distribution with Apt or something similar and suddenly we just didn’t have a need for Tucows anymore.
Yes, SF pages were horrible. But.. at least they were something. I can’t figure out why GitHub doesn’t try any harder to get people to document their stuff. Maybe they could have a form to fill out, describe what your project is in 1-3 paragraphs, system requirements, build steps, do you accept pull requests (y/n), etc… From that a page could be auto-generated that would beat the pants off most projects’ current README files.
Add a commenting system and tag suggestions and maybe even an up/down vote to that like it’s 2006 and you would have a platform that a community could really build around.
To be fair, GitHub has Wiki pages and static webpage hosting to go along with it all.
But the nice thing about a Readme is that it’s simple, and you were probably doing it anyway. It’s the minimum effort, which is sometimes all you want to make.
I’m still worried about what happens when GitHub goes belly-up, but I guess that’s when the distributed nature of git will shine.
@Fangs the car
It wasn’t quite that linear :)
RCS (Revision Control System) was a direct ancestor of CVS. Early versions of CVS were more of a ‘front-end’ rather than a replacement. SVN was intended to address the shortcomings of both.
At approximately the same time, Microsoft had it’s own proprietary source control system, SourceSafe, now Visual SourceSafe. In addition there were a number of other proprietary commercial systems such as IBM’s ClearCase and Bitkeeper.
Linus Torvald’s wrote Git after BitMover announced they would no longer provide free licenses to the open source community. It’s a long story but basically it centres around the OSDL’s decision to continue paying a developer who was reverse engineering Bitkeeper in clear violation of it’s license.
Ah, RCS, that’s the pre-CVS one I was trying to think of.
I didn’t really mean to provide a full history of version control in my comment any more than I meant to imply that Eliot should have. That’s a whole ‘nother article by itself. My point was just that the way it was worded made it sound like Git was first and Linus Torvalds just invented the whole concept of version control out of thin air. Hopefully all here know better but.. you never know. Maybe there are some hardware guys here that are just learning about software…
Oh.. that and I hate GitHub. Well… more accurately I hate the effect it has had on open source development in that too many projects are nothing but a source tree on Github with a very sparce README file as their only documentation. All too often I have searched Google for software to perform this or that task and it plops me down at some GitHub page where I can’t even find an explanation for what the software does. Is it what I am looking for or just a strange, spurious Google result that has nothing to do with my search terms? All the Readme says it follows the usual configure/make/make install build steps!
“I didn’t really mean to provide a full history of version control”.
Oh I know that, I wasn’t suggesting otherwise. Like yours, my comment was aimed more at people unfamiliar with source control systems.
I am an open source developer, and have no idea what are you talking about ;-)
Serious open source projects pretty much always come with documentation, in the source code, which is generated
and posted on project page or github wiki, or you have to build it yourself.
I’ve build a community/site for for open source hardware authors to share and sell their creations. You’ll find it on https://www.openhardware.io
Neat site. CSS renders slowly on scroll though, especially mobile. Try profiling it. I suspect it’s the use of background-image.
I’ve released a few OSHW designs and never got a pull-request.
I’ve also participated in a collaborative OSHW thing, and the way pull-requests work there is that when someone makes a change, they’ll order up 10 PCBs (the usual MOQ), build three, test them and forward one to the upstream maintainer with the pull-request. That’s usually no problem because the extras are approximately free.
If the pull-request comes with the resultant hardware, it’s much easier to validate that the changes are good and removes any need for the upstream maintainer to re-manufacture before accepting the request. So, pull-requests can definitely work within the context of a collaborative hardware project via git.
The relevant differences between HW and SW are not around issues of github, manufacture cost or collaboration, but:
– you probably only need one of whatever it is, and
– the installed base does not benefit from contributed improvements.
So while contributions might be happening, probably no one is going to bin their build and make a new one just to get the changes unless they’re hugely beneficial. Where an installed-base is a network-effect for software projects, hardware communities do not gather the same benefits.
Strangely, I feel like open-source software has the LEAST benefit for hobbyists and the most benefit for very large corporations. When you have the choice between buying a few thousand seats of Microsoft Office or downloading Libre Office / Open Office and paying one or two guys to program in whatever features your company needs that are lacking, the open source solution will come out ahead.
But for the hobbyist, you are going to do a lot of work and end up with no money at all, and still have to work a day job to pay the bills. It is a great benefit when OTHER PEOPLE open source stuff that you can use, but your own efforts will not get you paid at all. Worse, companies may come along and exploit your efforts in commercial products and make money off your work while you still get nothing.
Open source hardware means the “hardware” filters out anybody without manufacturing ability. If your thing is popular, manufacturing companies in China will make some good money off it!
I started programming as a kid in the 80s. Our computer was dated then, it was a Tandy that ran MS-DOS. I learned quickly that no matter how hard I tried all my efforts as a hobbyist were for my enjoyment alone. Why? Because DOS only came with a BASIC interpreter. There was no compiler. The least expensive compilers I could find were 100s of dollars in 80’s money. When step 1 of learning to use your ‘product’ is ‘learn to run the BASIC interpreter’…. you don’t have a viable product!
Today Windows, if you choose that platform has a free version of Visual Studio available for it. Why the change? I fully believe it’s because now there is Linux and also other free Unixs are a thing and they come with their entire development package for free. Furthermore, those open source development tools have even been ported to Windows. You don’t have to buy Visual Studio to write Windows programs. If they tried to guard their compilers like they did back then they would quickly become irrelevant.
If I were a kid starting out today oh how different it would be… and it’s because of OSS.
So, let’s look at what you are saying…
“But for the hobbyist, you are going to do a lot of work”
No, it’s a hobby. It’s something you WANT to be doing. For you, in this situation it is not work.
“and end up with no money at all”
Yes, by definition. If you were doing it to get paid you would be a professional!
” Worse, companies may come along and exploit your efforts in commercial products and make money off your work while you still get nothing.”
Nonsense!
First, you did get something. There is some reason you wrote and released that code or designed that hardware in the first place.
Maybe you wanted recognition. There are plenty of licenses you can release your stuff under that require anyone who distributes it (including commercial companies) to include attribution to you. If that’s what your after then the more distribution the more recognition. Let them come and market the product!
Maybe you wanted collaboration. Great, so use the GPL or something similar! If you catch them selling a modified version without releasing the modifications then contact the OSF. This worked out great when Linksys tried it. We probably wouldn’t even have Wifi in Linux without resorting to using windows drivers and ndiswrapper were it not for that!
Maybe you just like making. If so then that’s your award. Maybe you did it because you wanted the final product. Well.. now you have it. In those cases why do you care if someone else makes a profit? What is it really to you? Sour grapes because you never tried?
This is why I don’t get all those noncommercial licenses. While I respect a person’s right to use them because it is the fruits of their labor after all I think it’s a stupid choice. We would be better off if such licenses were never even invented. If you want to make money selling your design then why open source it at all?
I think too many hobbyists dream about going commercial while not actually wanting to do the work. Remember, it isn’t just design item, sell goods for money. There is marketing, supply chains, making the design optimized for mass production, support, dealing with customers. DEALING WITH CUSTOMERS!
Finally when you get all this mastered now you need to come out with version 2 in order to keep people buying. You aren’t designing new things anymore, you aren’t following the new ideas you dream up in your head. All those projects you would like to get to one day… never gonna happen! Now it’s endless iterations, making the same tired widget or app you wrote years ago just a little bit better so people will buy it all over again. How boring!
Going commercial is how a hobby dies and becomes dull (or stressful) work. If that’s your dream then follow it. We all have to make money somehow! But… if not, if you just want to enjoy your hobby… so you design something.. then someone else who does want to make their living that way happens to make some money off of your design?
SO WHAT?!?!?!?!?!
My point was simply that, although open-source is often seen as a hobbyist thing, actually large corporations stand to gain the most from it, and hobbyists stand to gain the least.
I’d say it is actually a net loss for the hobbyist because as soon as you release the code, people expect you to maintain it, to listen to their demands, to integrate their changes, etc. All the fun of a full-time job, none of the perks, like money to live on, health benefits, etc.
You say the surest way to kill the fun of a hobby is by trying to go commercial. I’d argue that releasing your code as open source is just about as bad.
“Modular design, with well-defined sub-units whenever possible, encourages improvement…Can you use off-the-shelf breakout modules that are sourceable on the cheap that can be unplugged and reused in the next revision? Maybe you should.”
Or you could just leave out the custom PCBs entirely, and build the whole darned device out of them: https://thecavepearlproject.org/2017/06/19/arduino-data-logger-2017-build-update/
Funny, I was reading up on the Cave Pearl project _after_ I wrote this piece. The PDF whitepaper that they just came out with is a very very good read. Plus, the fact that they’ve stress-tested and optimized the design every which way is very appealing to me.
Double-plus recommend.
(Haha, is “they” you? Face red. Great work!)
One of the barriers I see to open source hardware is precision and accuracy- namely how to get them, and how to inspect for them. I am a Mechanical Engineer with a pretty well equipped garage- 2000lb lathe, Bridgeport,etc. I may have gage pins to inspect a bore to .0001″ precision- but how many others do? Is it reasonable to expect this? Because of this fact, a design that works for me may not achieve the same result for the guy just starting out with a Mini Lathe and a pair of calipers.
The way I see open source hardware being very successful is documenting the entire production process flow- from raw material to finished inspection, with in-process inspection steps documented along the way. It would be fairly straightforward to standardize on a standard set of inspection tools- say a 0-6in depth Micrometer, a 0-1 and 1-2 micrometer, and a pair of 6″ calipers. That way, once someone has acquired the “standard” measuring tools, the processes ( and manufacturing is all about process) are designed for someone with just those tools to be successful. This would be a very cool approach!
I think its a matter of software can easily be ‘built’by downloading/installing tools. Its no where as easy with hardware. You can still put the designs on something like GitHub, it just not going to get utilized nearly as much.
The missing part is the compiler – the Open Source Microfactory. Universal access to an open source microfactory is a current missing link. We aim to address that with our Level 1 microfactory consisting of 3D printer, laser cutter, cnc circuit mill, plus filament grinder and extruder for making 3D print filament. Level 2 microfactory would include heavy CNC machining and CNC torch table to make larger products.
“Here’s the schematic of the thing we made” is shallow. “Hey, we want you all to take part and make this thing significantly better, oh and here’s the schematic to help you do so” is deeper.
Ok,so you want open source hardware to be a thing.
This is actually easy if it is driven by standards.
first thing’s first:
1. A common opensource library of component schematic symbols and IPC footprints. This will keep all schematics functioning properly. There will have to be rules and a curation process / comittee to keep it all clean.
2. Product Designs will not be single sheet schematics, rather they will all be considered applications or, a linking of smaller functional schematic blocks. So each design will start with a high-level block diagram. Each block will consist of an individual schematic sheet whose inter-schematic nets are shown as connection points on each block. Altium can do and does this easily. There will have to be rules and curation process / comittee to keep it all clean and compatible among the different EDA tools.
3. Each functional block will need to be tagged / searchable by purpose and rating / and have some kind of a vetting / voting / testing process to promote designs that are successful. There will have to be rules and a curation process / comittee to keep it all clean and compatible among the different EDA tools.
4. The end result would work like this: You start a design by making a basic block diagram. You then go “shopping” on a website / App front end that has all of the curated functional blocks with searchable tags and votes or some other ranking scheme. Perhaps there should be a “I built it and tested it, and it works” vote counter as well. You select and download the functional block schematic that will come with a BOM that uses the open source parts library and footprints and incorporate it into your design. At some point perhaps this can include pre-done PCB layout chunks for these circuits / sub-circuits. If the library is common and standard and includes a manufacturer’s part number you can even keep an updated price for each functional block and price out one vs. another further reducing the amount of work to be done for each new design.
You would then be able to re-use designs that are created by other people in a common, sharable format. If there was a dedicated tool to use / access this curated information, the new functional blocks that you create could be saved onto the repository as “not yet verified / new.”
If the license / focus was kept on open-source sub-circuits or functional blocks instead of full end products (which are the sum of subcircuits) you might win over commercial designers and begin building a database of functional blocks / subcircuits pretty quickly. If a company that sells components would like to sell a crapload of components, they could sponsor design blocks that use their parts. That might help pay for some of the curation, etc. Some companies already release schematic symbols / IPC compatible footprints / 3D models for EDA tool usage.
There are already commercial companies / programs, usually subscription based, that do some of these things.
I already do this for the company that I work for among the designs that we develop in house.
Is your software for managing the design libraries open source? What are the best open source tools that handle part libraries like you suggest? We just do it with wikis and FreeCAD – see for example http://opensourceecology.org/wiki/OSE_Part_Library#Construction_Set_Modules
Yeah…I’ve tried to fry this egg for a while now. The underlying problem is: how do you transmit all the relevant design data and source materials to another person, and how to do you then re-integrate those change if a revision is proposed. The problems I’ve seen fall into the following broad categories, none of which really has a great solution. The details are really long, so I’ll summarize first:
1) All the tools store their config differently and often wrongly, making it difficult to version the development environment and config as well. And, yes, you need to do that for long-term projects if you hope to resurrect them; I recommend virtual machines.
2) A standardized library (as mentioned earlier) is moot if the design data carries the entirety of the partially-customized library with it.
3) The number of tools and types of just “information” that’s needed to be kept for a real design is orders of magnitude larger than just source code and board layout, which means that pull requests for any complexity of change will almost certainly be made without a full understanding of the ramifications, and will necessarily affect a wide swath of the design. Not everyone is able to get their head around all the data that went into the original design, and they definitely won’t if all the artifacts aren’t there to study.
4) Nearly all assembled electronic products offered for sale have some level of regulatory approval or certification required. Just because you don’t know that, does not mean the FCC or even the FDA won’t sue you.
5) Unlike with advanced software refactoring tools, there is no end-to-end design system that properly attends to the hardware-software transitionary boundary. If I want to change the pin assignment and sense of a signal, I change the schematic, and the board, but it doesn’t update the source code with port assignments, nor does it change the sense of the signal. Bah!
6) When you have multiple product designs ongoing, most engineers will eventually resort to some method of numeric/coded part/assembly identification. Few if any of the version-control systems like having custom version numbering hierarchies. As you manufacture your product and sell it, you’ll be slowly accumulating minor forks of the product that represent a production version with some minor fix, leading to a sea of “current” data that only applies to a small number of units.
7) In a product of even low complexity, the number of distinct tool (suites) grows and grows. There’s PCB and Schematic, and coding tools and 3D and web design tools…. The issue isn’t the underlying complexity, however. It’s that whenever a change of “sufficient complexity” occurs, it will necessitate updating the design across typically half to three-quarters of your tools. Doing that in an atomic, reversible way, where you have the proper granularity-level for each atomic change is challenging, to say the least.
8) There are some production-focused actions that WANT the version number in the file name that’s being run, so it can be verified against machine setup sheets, tool-changer assignments, and stuff like that. There are some scenarios in which you need to have multiple versions of the same file on-disk, side-by-side.
Yeah, that seems like enough. I deal with this situation every single day (even weekends, as you can see), and the available commercial and OSS solutions have not yet really taken a hard look at how engineering data functions within an organization, and how it hangs together to form a “design”, even with just a few people / contributors. The amount of customization needed for any software-development version-control system is immense. And, I don’t even do chip design anymore. In those, we’re talking versioned netlist, layout, library, and simulation databases in the tens of terabytes for a large chip. I suspect GitHub, even for all of Linus’ prowess, would literally choke on 100 people making changes into a set of files that big. But hey, isn’t GDSII an ASCII format? I’m sure the diff engine will be fine! ;-).
I hope that provides a little broader perspective on what I’ve seen from the trenches of fast, agile, and integrated in-home product development over the last several years.
The long version awaits your already-drooping eyelids…..cheers!
=================================================================
1) Each tool maintains its configuration data separately, so necessary configuration files are often not “in the repo”, which means you have to find, maintain, and possibly move them so they are in an area that can be checked in for the projects. Honestly, the best way I’ve figured out to archive the design environment is to use virtual machine and drive images. They’re not small, but they come back up the way I left them :D.
2) Although I agree that hardware design interchange is impossible without some library, I think the previous comment about using a standardized, committee-built library is both wrong and misguided. The problem is not that everyone needs to use the same library, it’s that when the schematic arrives at your computer, it does not **contain** all the dependencies, like a PDF file can carry non-standard font glyphs instead of trying to find them on the computer. There should be an “incoming design” tool in all the ones we use that goes through the dependent components, determines if there are version and substantive differences, and then advise or update the part. Although some tools do this, not all do. The problem isn’t that they don’t tell you, it’s that there’s really no need…it should keep the dependency tree and all the leaf nodes for each design version. I’ve yet to make any design where 100% of the components were in any standard set of libraries.
3) Each of the more-significant projects I’ve done start with multiple conceptual drawings; have an engineering notebook that is required to be checked-in; has a bunch of tool installers that have to be archived for when the project is resurrected; has a tested set of cut- and print-parameters in a catalog for use in the design and implementation; has production instructions and notes that are updated pretty much every “dot” version. There are entries in the master part/drawing catalog that needs to be updated. It includes documentation, marketing literature, the web site, pricing spreadsheets, business-focused breakeven information to determine if it’s even viable to build, mechanical design/fab/inspect artifacts and procedures, electronic schematics, documented theory of operation and any patent-able innovations, firmware and application source and test code, interface api/protocol specifications, bills of materials for all assemblies; regulatory conformance information and testing methods….the list just goes on and on. They all have heat-studies; and diagnostic flow charts for repair and maintenance. They include life-test and SPC tracking results. The list just goes on and on…. I guess my point is that the complexity of a full-on integrated product design through early production is such that almost nobody but the originators will be able to grasp the true implications of even a small change that actually affects performance or operation on that original design. Change an R470 to an R330 for a brighter LED? Sure, that’s easy! Change the sense and pin assignment of a signal on an MCU because you want to use a different port, and make sure that new pin will actually function in the software’s interrupt structure? Yeah, enjoy that spelunking challenge, Mr. You’ve Never Seen This Design Before.
4) Similarly, as someone who is decidedly attempting to build for-sale products that I produce by hand, myself, the amounts and kinds of documentation needed are a LOT more than you’d think for any legitimate in-market product. For example, most hobbyists don’t even realize that when a product requires UL/CSA, FCC or FDA approval/certification, there is only a limited type of changes allowed before a re-certification/submittal is required. And heaven forbid you’re asking for a waiver from, say, safety features that are in the FDA regulations. Better bring lawyers. My point is that some designs are very much NOT suitable for open source, even if the desire is there to provide makers that functionality. It would be very difficult to impress upon people their need for regulatory approval for any for-sale derived products. The liability exposure for me as a contributor of the original design would be huge! Indeed, my biggest worry would be that people would take my (relatively!) safER design and REMOVE the safety features in their iteration. Remember: there are almost NO products that can be sold that they have zero regulation, nor have zero product liability attached. From returns to liability claims, if your design documents and artifacts are not in line, a jury could find you negligent and culpable (Think LLC!) An example might be a CNC engraving laser that blinds someone. Even when sold as a kit, the costs of a lawsuit are immense, and when a jury finds out you didn’t keep the records the FDA said you should, or you left out a required safety device, well you’re screwed! The law will no longer be on your side.
5) More on those linked dependencies…in hardware design, like software, “signals” (variables, structures, objects) that communicate some meaning between components can really be considered just a hardware manifestation of the variables, and vice versa. Unfortunately, when something like a pin assignment changes, or a pin level-sense changes, NO tools stitch the entire system together so that the software code is automatically changed to match the changed pin assignment and board. And forget about timing changes! Nobody keeps track of those for us, which means the normal software-consistency checks that people build for source-code check-ins (you guys do that, right?) aren’t even possible, much less easy. Not only that, but because the design-domain systems are so separated, you have to manage the change/versioning separately in each tool, within the limitations of that particular too. I know of no decent version-management toolset that can create that level of complexity of integrated, multi-domain change.
6) Given I do MULTIPLE product designs from idea through prototype and early production (24 complete ones last year, on #8 so far this year), they all have to fit within a design-data organizational system I call the Fully Qualified Build Identifer. That includes product/assembly/part numbering, naming, and a 4-field version number. For example, 2018-002-010 eAFC Control PCB v1.01.004.056. Like it or not, I’ve yet to find anywhere near that amount of version traceability in any system. The fields are: major product, product edition, design version, and fabr/toolpath version. All are needed, but more importantly, all are essentially forks until the final set of files are deemed production-ready. Most modern diff-based systems do not well handle what are essentially infinite forks on the same set of files. Depending on production volume, return rate and scrap/repair decisions, you might need to keep literally dozens of complete, slightly varying design reference documents online and available. If you can’t find a definitive schematic for that board, debugging can become shadow-boxing. Especially when you shipped 100 units this week, and you have 10 that came back just last week! This happens, and it happens more on early, small production lots.
7) As mentioned in 3, the number of tools grows pretty much weekly: Fusion360 (and others) for 3D CAD; Vectric, Fusion and BobCAD for toolpath generation; EAGLE for schematic and PCB. Slic3r/Cura for 3D printing. There are areas for screenshots and photographs, STL models and toolpath output. Keeping the data separate isn’t nearly the problem as keeping the DEPENDENCIES straight. There are entire solution/project hierarchies for both (different versions, of course!) of Visual Studio, Atmel Studio and the Arduino IDE. So, it’s a pretty broad and deep archive structure. The scenario I’m thinking about is that of a normal product life-cycle. I make the design, I test it and prototype it, and I arrive at some collective “version” among all those disparate, non-integrated tools, that I believe can be produced. Then, say I make the first set of units, and a customer finds a problem. Okay, so the next lot gets those changes. Then a parts manufacturer changes the part outline or parametrics for some part, and I have to design in a different one. Now, just exactly where should those changes go? Clearly the customer’s change goes in N+0.0.0.1, or maybe N+0.0.1 if it’s something that goes all the way to how the device functions. But either way, it goes into a FUTURE design. Now, what about that component change? If I still have some board of version N to stuff, do I rework those? And just what version do I assign to that batch of boards that were modified during production to match the updated schematic? No, you cannot just claim they’re the same version. Why? Because when they come back for service you have to be able to separate the two to figure out the problem and fix it properly with the right parts. Oh, but the fun doesn’t stop there. As you move farther and farther into the list of minor-versions that accumulate in your customer base, the number of forked versions only grows.
8) In hardware, design, you often WANT the version number inside the file name of what you’re using. Think about CNC toolpaths where you’re knee-deep in the machining, making small tweaks as you go. In those cases, you might have half-a-dozen different trials of a toolpath. Having an auto-generated (yeah I wish!) version number attached to all the files would make it so much easier to write scripts that hang everything together as the sparse network it is. Sparse, that is, among the many versions of each hierarchical level/component of the system. When there’s multiple versions floating around, the computer should do it flawlessly by itself, and when I tell it something specific to do instead, it should do that. I mean things like substituting in an older feature-level toolpath for one that’s not working right, in a longer collection of GCODE. If the different versions can’t co-exist on disk side-by-side, this becomes a nightmare.
Those are the major problem’s I’m seeing with even using a repo like GIT to store the versioned designs. Forget whether it’s good or bad or awesome to open a design to OSHW/OSS model and make it available in the public domain or accept changes. I’m finding that tools built for software-development don’t operate in the reality of the situation: that any significant change is in fact a forking change of the **entire** design. Why? Because they exist as distinct physical entities that you, as producer, need to keep copies of the data that generated it. All of the data.
The above is my OPINION. I don’t claim it as fact, just what I’ve come up with to solve a problem others seem to have not.
Great insights, thanks for spending the time to document them.
Oh yeah, I forgot one other thing. The original blog mentions passing around custom libraries of parts between EAGLE and KiCAD. In some instances, especially when integrating complex chips, MEMS and larger electro/mechanical components, it is very important…I’d say REQUIRED…that you use ONLY the manufacturer’s provided mount specs. It’s not unreasonable for an Engineer to insist that they provide real models that they warranty, any more than it would be unreasonable to expect them to meet their own datasheets. The library is just another manifestation of the same mechanical / pinout data that we agree to when I sign a purchase contract (or these days, click Purchase). If they warrant one form, then they should warrant the other. Applying this rule consistently can prevent some MAJOR headaches in your design when you use a modified, or self-made library that is somehow WRONG.
Before people go telling me that no, their design data is perfect, let me be perfectly clear: I came to this conclusion when I found consistent errors in major-brand MCU pinout naming between the manufacturer’s datasheet and a for-pay, commercially-provided third party library. When MY boards come back with pinout errors, what’s to be done is always the say (fix it!), but it matters a LOT to me how I managed to include faulty data. As W said, “Fool me once, shame on you. Fool me twice? Can’t….Can’t get fooled again!” (I think what he meant was it’s our responsibility to not let unreliable information sources continue to be treated as authoritative). And so, I’ve found that the only one I’ll accept crucial libraries from are the manufacturers themselves. And they’d better check them or they’ll hear from me…in a good way!
This really doesn’t apply to commodity chips, caps, R, inductors, power bricks, where there’s a company that gives volume discounts out beyond 10K pieces. No, I’m talking about those components where if they’re the wrong size, your entire production run stops. Same with those modules on eBay…keep that part of the design un-finalized until you can positively verify the pinout, dimensions, power-draw, heat-dissipation, airflow requirements, etc…. Let’s just say that when you find out too late the mount for a part is a mm to the left than the spec said, a solid root-cause analysis will happen.
…in my opinion :D.
Cheers! So glad I found a place to unload all the design-data travails I’ve made it through.
Quick question: Why is this article tagged “Biography”?
My only remark is: “Software is really just information, and the storing, modification, duplication, and transmission of information … software is essentially free”
In the current climate and substantial progress that are being made in open source, I think it’s very important for the many, growing contributors to understand that although it’s easy to deploy and distribute software, it is not free.
Software does require physical resources to use. I think that’s important because as the open community grows larger they need to understand that creating these software systems does have a physical impact on natural resources.
Ie. You can open source cars, but people shouldn’t make a fleet and rally race them through a nature preserve.
You can see this large open resource use become a problem with software such as Bitcoin. In which now people are taking advantage of lack of resource regulation workout gaining any actual utility from Bitcoin.
I think as open source grows this awareness and responsibility should grow equally. Software although easy to create, distribute, and use is NOT resource free.