Obviously, it's free and open source, with no board size / layer limitations.
On the other hand, Eagle is still much more widely used in the DIY community, and most my-first-PCB-like tutorials are Eagle-based.
Kicad has for years suffered from the binary release being really, really outdated.
Kicad development feels pretty fast-paced.
It has most or all of Eagles features, and some nice advanced features Eagle doesn't have. Especially it's PCB routing support is much better. For example, it supports push shove routing[1] and automatic trace length matching. It also shows the netname on pads (in Eagle you have to use "show" all the time). On the schematic side, It has had hierarchical sheets for many years now, whereas Eagle only gained hierarchical design support earlier this year in version 7. Things like that.
There are minor workflow differences in some places. For example, it uses key combinations instead of typed commands. There's a netlist generation step between schematic editing and board editing, so going back and forth between the two isn't as straightforward as it is in Eagle.
The hobbyist community has been switching over to KiCAD, to the point where I believe KiCAD has a significant majority over Eagle in OSHPark orders. A lot of people switched with the new Eagle licensing model, which they put on hold due to backlash.
I'm on support at OSH Park and we're still seeing a sizable majority of Eagle boards, but KiCad is definitely on the rise. I've got the impression that a lot of folks have been turned off by having to get the daily builds, so I'm incredibly excited to see the stable release. I'm expecting we'll see KiCad come to parity with Eagle over the next year or two.
We're also working on being able to take .kicad_pcb files directly, in the same way we take Eagle .brd files now. In the meantime, I wrote up a page with some KiCad screenshots and instructions for how to generate the gerbers and drill files we need. [1]
The major issues we see can be solved by checking the Protel naming format option so we can detect layers correctly, and by putting the board outline by itself on the Edge Cuts layer.
Laen mentioned on the amp hour podcast a couple of years ago that kicad was the majority at the time. Later on he said that it was just a blip at the time for some reason and eagle became much more dominant.
I wish I could upvote your post more for the middle paragraph. Direct kicad_pcb input in to OSH Park will be fantastic!
We do! They're way behind Eagle and KiCad, but they're a fair and growing number. Our current challenge is to keep expanding our ability to automatically detect the default gerber naming scheme so it doesn't matter which CAD package you're using. I know we've recently really nailed down the Altium variants (Designer, CircuitMaker) but I'm less sure about Upverter.
One of the downsides of accepting gerber files is that a lot of folks rename to match our suggested naming pattern to be sure the files work, so it can be tough to determine which CAD package was originally used. Plus, we still get gerbers from some rare ones like TraxMaker 2000 or Ranger 3.
FWIW the old lead dev had a philosophy of "everybody should just compile the most recent source" which is why there hasn't been a stable release in a long time.
The new lead dev wants to do stable releases much more often than in the past. We'll see how it goes. KiCad ended up in a "feature freeze" since ~May which slowed down dev for the last six months.
I generally end up using an online tool [1] for high pin count parts. It's not the best though, someday I will write something better.
BTW, in most professional contexts, parts are all created by the engineer - vendor part libraries are pretty rare. I know Altium is trying to change that, maybe soon we will see something similar happen with KiCAD.
The UIs of both are pretty terrible so even on that point.
The schematic tools are pretty similar in their capabilities.
KiCad's pcb tool has some much more advanced features (mostly added by a group at CERN in the last year) such as a push and shove router, differential trace routing and length tuning which can auto add serpentines, etc. It is not 100% feature complete compared to the old pcb engine though.
KiCad also has some nice user scripts for importing/exporting 3d models for mechanical work now. (search kicad stepup)
All in all, they are close to the same level right now.
A lot of KiCad is in flux right now though because a lot of contributors have come on in the last couple of years. Much of the program is being rewritten/has been rewritten recently. It doesn't seem to be slowing down either.
full disclosure: I help develop KiCad a bit. I tried to be pretty balanced in this comparison though.
Neither tool has a good way to do matched-impedance traces. Both rely on scripting or a plugin to do this, and the feedback is not real-time nor can you make design rules on matched nets.
Also, neither tool integrates smoothly with simulation software yet. One of my pet ideas for a while has been to integrate EEScheme, the KiCad schematic capture tool, with ngspice, an open-source spice engine. The integration would include things like probing voltages and currents in the schematic to make graphs appear. Or, associating spice models with library components.
However, this would also require some way to create "simulation-only" versions of schematics. Typically, you only want to simulate a sub-section of the schematic at once. No other schematic tool, even the big ones (Cadence, Mentor), does this very well yet.
Having just switched from EAGLE to KiCad I think I'm qualified to offer an answer to that question.
The short answer: it is better. If you are considering switching, do not wait, just switch. I should have done this sooner.
The longer answer:
Both tools have drawbacks and the user interface is bizarre in many ways in both of them. That said, KiCad at least is being regularly improved. I got tired of waiting for EAGLE to fix even the most ridiculous UI flaws. It seemed just as if EAGLE wasn't really developed anymore, just stuck way back in the 90s.
My schematics look much better these days. Hierarchical sheets help, too.
The separation of symbols from footprints is a great idea. As a practical example, I already have a small library of Texas Instruments packages (DRC, DRV, etc), which means that I can often just draw a symbol and immediately assign a verified footprint to it. No copying, and the footprints are shared, so if you modify paste coverage once, all parts using that footprint can immediately benefit. This idea is a clear winner.
Routing boards takes significantly less time than in EAGLE. Mostly because of the push and shove router — I don't think I'd even take on some boards I'm making these days without it.
The layers seem to be better organized: you don't get a hundred layers with weird names, the set is clearly defined and it's easy to understand what they are used for.
3D visualization is really great. I didn't think it would be useful, but I can't live without it these days. All the components in my libraries now have 3d models attached, even if the model is a simple cube. This helps greatly when designing small stuff that is supposed to go into real enclosures. Exporting to decent CAD packages isn't quite there yet (you can do it, but it requires significant effort), but the ability to instantly visualize your board helps a lot already.
The library management is as bad as it was in EAGLE. Perhaps slightly better because you can use github repos as sources, but in general it's a crappy experience. I hope this will improve in the future.
Finally, price is an important consideration. EAGLE is not free. If you do anything commercial, EAGLE suddenly starts to be quite expensive, especially if you want 4-layer boards or larger boards. Other commercial packages are even more expensive. So if you are a serious hobbyist who wants to produce small 4-layer boards at OSHpark, KiCad is really the best option.
In general, I see no compelling reason to stick to EAGLE unless you have zero time for learning new things.
I completely agree, and I also wish I would have switched sooner.
The only thing I'd add is that anybody who's thinking of switching should treat it like picking up a new, very different programming language. It took me three weeks with several boards and a video tutorial series to finally get comfortable that I can use the tool without constantly looking up hotkeys and documentation (which is really good).
The thing I recommend is to never assume that the way KiCad is doing something is the only way, and to Google aggressively. A good example is the 'Move' tool vs the 'Grab' tool. I watched a guy nearly swear off KiCad because he only used Move and never Grab, so he was moving wire segments individually. If he'd read the documentation or searched for the answer, it would have been there. These tools are not particularly intuitive.
The best part of taking some dedicated time is that now I have 2-layer and 4-layer templates with my design rules, custom project settings, and a bunch of custom hotkeys. It makes all the difference.
Gaining an understanding of your enemy's background, capabilities and motivations is not a 'courtesy'. Rather, such knowledge is needed to achieve victory.
"If you know the enemy and know yourself you need not fear the results of a hundred battles."
You are making a fine point, but I think the spirit of your comment is quite different from the original from @williamle8300.
Your point a agree with on a big picture level, the war fighters and analysts and policy makers need to understand capabilities and motivation of the enemy. I'm not a war fighter and I don't believe it makes any sense for me or other Joe Average Citizen to empathize or understand a psychopathic foreign enemy. Understanding in this case won't get you far.
The shooters in the San Bernadino massacre were Syed Rizwan Farook and his wife Tashfeen Malik. IMHO it's important to understand their background and motivations. Know your enemy.
"In terms of construction scores (from 1 to 10 where 10 represents a perfectly built trolley), men averaged 8.9 with instructions, 7.6 without; the women averaged 7.5 with, and 5.7 without."
My version is a bit different: It really helps to know my editor well enough that I just look at a spot on the screen and the cursor goes there (without conscious thought).
That's probably not quite the same thing as the article is talking about, though...
I can do this in verb-noun structure of VI/VIM, but for some reason the somewhat richer but less structured Emacs movements don't flow as easily. I've been using either for decades.
I find that 'excess mental activity' blocks peak-performance when coding. Excess mental activity can be described as 'aversions/judgements/fears' about the work to be done - self-talk like "this looks hard", "fuck I hate this build system", etc.
I try to just stare at the code without judgment for a few moments, then let the fingers do their thing. Sort of a meditative practice - quiet mind instead of quiet eye.
The clock boy incident was a clever hoax. Ahmed and his family may not be great engineers, but showed themselves masters of our media and legal system.
It wasn't the oxygen that killed the Apollo 1 astronauts, it was the fire. Oxygen can be toxic at high pressures (which is why deep divers use a mix with helium replacing some of the oxygen) but AIUI breathing 100% oxygen at ordinary atmospheric pressure is fine.
TLDR; Muslims serve in Western Armies, so shut your pie hole about Muslim terror attacks in Mali, Paris, Sinai, Boston, London, Madrid, Bali, New York, etc. etc. etc. etc.
