Thanks, Ondsel - it was a worthy and welcome attempt. And you left FreeCAD much better off than when you found it. For that reason, Ondsel may be shutting down, but it is anything but a failure.
Every time I have a personal project and want to make a simple CAD drawing of a building or a simple model, as I would using AutoCAD at work, I go through the same song and dance. I look around at the options online, my jaw hangs open at the cost of any commercial CAD subscription/licence, then I get frustrated by a glaring lack of functionality or useability while trying some free/open source solution, and resort to a 30 day trial or MSPaint/paper.
Some of the comments already mention how blender's existence is predicated upon it filling a niche in certain senses, instead of trying to achieve feature parity with an entrenched giant. That makes sense, and it's unfortunate, as this space could use an open source option with Blender's polish. In my own industry, mining, I am certain some commercial interests would happily make their product an extension/plugin for a polished FreeCAD (or other), were it at that point.
Blender is often used as an example of open source polish, but I think too many people focus on how it exists today and not how it evolved. Blender got its start as a commercial tool that a pool of people raised €100,000 to pay to make it open source. And for years Blender's UI was criticized as being too difficult and too different from tools like Maya. It's a marvelous tool today because a dedicated group of people donated their time to improving it or were sponsored by others willing to contribute monetarily.
FreeCAD isn't as refined as Blender, but it also hasn't had the same level of support. I've found the maker community particularly critical, often in uncostructive ways, around OSS CAD tools like FreeCAD or SolveSpace. It's hard to compete with commercial offerings that have full time designers working on them. To get there we need volunteers to work on the project and/or folks willing to fund development. Ondsel demonstrated how well that could work for FreeCAD. But, the maker community has largely been unwilling to contribute either in terms of cash or time. And many take to publicly bashing the tools, which doesn't exactly entice those volunteering to go out of their way to help.
We could have the Blender equivalent of an OSS CAD package, but people are going to need to step up and contribute. I appreciate that you often have a time sensitive task and going with a commercial tool is more expedient. That's fine, of course, but that also isn't going to help advance any of these OSS tools. Just also be aware that you're at risk of losing your design as well since commercial licensing can change on a whim (e.g., Fusion 360 preventing STEP export for free accounts -- this decision ended up being reversed, but should be concerning).
I have a similar problem, but for electrical diagrams. I want to draw out diagrams for each of the circuits in my house and none of the free options are good enough.
I wanted to make diagrams for an embedded system circuit I made and ended up using PowerPoint. All of the free options seem to be focused exclusively on PCB design and not making nice graphics. Fritzing which is what a lot of people recommend is now a paid for application.
I posted and then deleted a comment as I was going to ask if you'd tried draw.io. Even when I worked in electrical design (infra+industrial), it was my go-to sketching tool to have open next to -CAD. What would you do to improve it for your use case, or are you lamenting that it isn't open source either?
It would be perfect if the symbols I wanted were already built in. There are some electrical symbols but they're very much circuit design focused whereas I'm looking for symbols such as these https://www.edrawmax.com/templates/1011842/
Definitely having built-in symbols for it would be nice. Regarding a titleblock, I found that custom data attributes on symbols and page backgrounds can accomplish as much as I would even need.
Create a page in your document called "Titleblock", format it and place dummy content if desired. For each "sheet", just select it from Page Background (you can set an image, URL, or another page in the diagram). For filling out information which varies, just have one titleblock symbol and add Placeholders for the custom data attributes which you add to it as well. (See: https://www.drawio.com/blog/placeholders) This is a common workflow in CAD as well just with different terms; i.e. a linked titleblock layout used for all sheets and a block inserted into the actual drawing with the attributes filled out.
Alibre (1) seems pretty popular with makers (good cnc support?). Not OSS but its a one time $200 purchase - sorta surprising you can still buy software these days :-P Alibre is more of a professional tool like Fusion 360, so there is some learning curve.
I second Alibre, I am using the pro version. I bought it in 2012, and I can't remember if I've paid for upgrades to keep it current since then.
I used it to design an injection mold and I am still using it for 3d printing projects. It's a capable program and on-par with SolidWorks or Inventor for basic modeling.
I haven't tried OnShape yet, but if I didn't have Alibre I'd probably look into that or another web-based program for new hobby projects. I like the idea of perpetual licenses but it's only perpetual for as long as it runs on your operating system.
I just can't get into the web based ones...I don't know why but they all seem slow and clunky to me. One thing I didn't like about alibre is the lack of Linux (or Mac) version, as I plan on ditching MS once my win10 box is unusable - I have no interest in that new AI crap MS is adding.
I did the free trial and it seemed ok - but I had too many bad habits from fusion...one thing that always tripped me up was the limit of 1 sketch per 'part'(?). It seemed to enforce 'best practices' much more then Fusion does, and I just tinker with hobby projects. They were very attentive though, and even called a few times to see how I was doing...
Also, I really liked the 1 time purchase vs. subscription
There's also Fusion 360 that's free for personal use. SolidWorks is better and worth $50 / year if you use it a few times, but for a one-off project, Fusion 360 is pretty good.
The issue I found with Fusion360 is that I don’t own my files. You used to be able to export locally but last I used it (a few years ago now) I was unable to export a file in a native fusion format with saving to the Autodesk cloud being my only option. This is hazardous as not only am I now at the mercy of Autodesk but they also expire files after just under a year so in need to ensure I’m logging into my account regularly just to keep some things that could happily live on a local disk.
However true that might be, I’d rather try to avoid wrestling with software for my data. If that’s really the case then even if it’s free I’m pretty sure you’re not getting your money’s worth.
I actually agree. If having copies of your files is important, subscribe to SolidWorks. It's inexpensive and better than Fusion 360. Most of what I use Fusion 360 for is ephemeral stuff that I print once and never need the design again.
Well, it's a non-commercial license. The $2000 limit is already kind of generous, especially since it's a profit limit and not a revenue limit.
Without having read the fineprint you could make a lot of revenue as long as you keep reinvesting the money into stuff related to your solidworks side-hustle (buying 3D printers, material, CNC machines, workstations, whatever).
I've had multiples of my students get into legal trouble over the years from using these. Just understand that almost all of these professional level software packages phone home even after being cracked, so you basically have to airgap your computer if you use them. It's a major reason why I steer them towards open source CAD packages, and towards the pro level CAD packages with usable free hobby licensing.
These are the kinds of projects I would love for philanthropic billionaires to get behind rather than political garbage. It’s something that can serve everyone everywhere
Sometimes I envy that although I am not a SWE. I work in a field that is so close with the open source and tech scene that we don't have to rely on commercial products like some other fields. It is hard to compete or gain enough interest in some fields of engineering to any open or free solutions.
Perhaps you mean proprietary. Ondsel is after all a commercial project.
The fact remains that proprietary software seem to be a license to print money, and with the ability to print money is the ability to entrench said software, such as heavy investment in software development.
This is a uphill battle for open source software, but it seems that open source software tend to keep improving in the long run.
>with the ability to print money is the ability to entrench said software, such as heavy investment in software development.
It seems like proprietary software has a big advantage when there's still lots of room for improvement, so that investment in further development pays off.
However, in some cases, there's little room for real improvement, and the thing becomes a "solved problem" for the most part. At this point, the proprietary companies then start enshittifying the software (look at Photoshop, now a cloud-based program) to try to extract more money from users, and to keep users on the upgrade treadmill. Part of this is probably from the way corporate politics work: when you're a manager with a team in place, you need something to keep that team busy, to justify your team's continued employment to upper management, so when you run out of useful improvements to make, you invent less-than-useful "improvements" (e.g., ugly new UIs).
This is where FOSS seems to be able to do well: it doesn't need to waste resources on useless improvements (we'll ignore GNOME for a moment as an exception), and can just focus on delivering the necessary functionality. Once that's done, it can just go into maintenance mode and people can move on to other projects. Until then, it can continue to improve and attract users to switch from the enshittifying proprietary stuff.
Wayland has its issues to be sure, but the X Window System was no longer suitable for modern systems; the justification for replacing it was quite sound.
GNOME I'll heartily agree on. But I've never liked GNOME myself (v1 seemed OK though) and have always criticized that project. I've always been a KDE fan, though admittedly they've had some similar problems and have handled some major changes rather poorly (esp. 4.0). Really, the desktop environments are one place where FOSS hasn't really done that well, frequently re-inventing the wheel for questionable reasons, or adopting questionable new design philosophies. At least there's a fair amount of competition in the space, so if one project rubs you the wrong way, you can try another; this proliferation of competitors also shows just how much disagreement there is in the community on this particular matter.
I really don't know enough about the audio stack changes; I can only guess that they found big problems with older solutions there which required major architectural changes, esp. for certain high-performance applications.
> this proliferation of competitors also shows just how much disagreement there is in the community on this particular matter
It is to be expected that there is a proliferation of different UIs if there is the possibility of making different UIs run on the same OS. The reason is that everybody has a different workflow, different aesthetic preferences, different ways of doing things (e.g.: leaning more toward keyboard, mouse, touchpad, touchscreen). The best thing I remember in this space were the dozen or so X11 windows managers of the 90s. The worst one is the single UIs for Windows and Macs. There are some ways to customize them but not as heavily as it is possible with Linux.
Wayland seems to restrict what's possible to customize but I might be wrong because I have no direct experience. I'm still of X11 because of an old NVIDIA card and frankly I could stay on X11 forever. I know that I'll have to switch sooner or later because of software compatibility. I'd hate to have to buy a new laptop only to be able to run Wayland. It's still good enough to work with me for my customers.
Do they? There's no lack of Electron UIs on Mac and Windows. What's even a native widget library on Mac and Windows today? Do Swift-UI and WinUI (v3 nowadays) count? It's not as clear cut as it was in 2000s.
Yes they do, that is why I clearly mentioned "still".
Native widget libraries is whatever the OS vendor puts on the SDK, and ships on the installers for their compilers.
The large majority of Electron apps that happen to land on Mac and Windows land, usually come from GNU/Linux shops, that also feel like targeting other operating systems, and since that is the solution for GNU/Linux, they dump it into everyone else.
In the process they help Google take over the browser ecosystem, and then talk about how M$ used to be all over the place with IE.
Native widgets libraries were historically those, who were only one that knew, how to talk to the display server. So if you wanted to write another widget library, you had to link to them anyway, to use them as a proxy. That's how Qt, for example, runs on Windows or Mac, using the old win32 api or Cocoa.
But meanwhile, the OS vendors got creative and pumped out a bunch of new, _more modern_ libraries, which have abilities that the old, "system" ones do not have. You want Acrylic design on Windows? Better be satisfied with WinUI -- which, in v3 is the recommended way to write native applications by the platform owner, and which is decoupled from system releases and from Windows SDK.
Electron apps are coming from any shop, that want to throw together some installable, locally running app and figured out, that paying HTML+CSS devs is cheaper, than paying C++ (or ObjC) ones. Having shorter development time is also something positive. It has nothing to do with Linux shops; there are Electron apps, that could be running on Linux if there was a will, but aren't (Whatsapp), or almost-electron-but-edge_webview-instead (Teams).
In 2024, the recomend ways to write GUIs in Windows are Win32 (your native widgets library), exposed by WinForms. WPF has parity with WinUI 3, in recomended way by the platform owner, officially communicated at BUILD 2024.
Doubled down at .NET Conf 2024 during the last week.
Regardless of the GUI framework from Apple, and Microsoft, those are managed bindings to the underlying native APIS (Win32 and Cocoa), which is why they also expose handles to do lowlevel stuff if one so desires, coding like 2000.
Webviews are a different matter, as they don't require shipping Chrome with the application.
It definelty has a lot to do with Linux shops, as they can't be bothered to support GNOME, KDE, Sway, XFCE, or whatever everyone else uses, so Electron it is.
And then they want Mac OS and Windows customers as well.
> In 2024, the recomend ways to write GUIs in Windows are Win32 (your native widgets library), exposed by WinForms. WPF has parity with WinUI 3, in recomended way by the platform owner, officially communicated at BUILD 2024.
| Many apps for Windows are written using Win32, Windows Forms, or UWP. Each of these frameworks is supported and will continue to receive bug, reliability, and security fixes, but varying levels of investment for new features and styles. For more information about these app types see the following tabs.
Yes, in Build 2024, there was backpedaling back to WPF, since WinUI is in terrible shape.
> Webviews are a different matter, as they don't require shipping Chrome with the application.
Electron also doesn't ship Chrome with application; it ships the rendering engine (blink) and javascript engine (v8). Which is exactly the same, as edge webview. Unlike edge webview, they are not dragged in by Microsoft Edge, the browser (so you get it whether you have an use for it or not).
> It definelty has a lot to do with Linux shops, as they can't be bothered to support GNOME, KDE, Sway, XFCE, or whatever everyone else uses, so Electron it is.
So how do you imagine such support would look like? I know a thing or two about development on linux, but I have no idea what would supporting XFCE or Sway explicitly in an app would involve. Unless you hyperbolize, right?
The only real decision would be choosing Gtk or Qt; the desktop environments have no real impact on your app and with Qt, you are getting the multiplatform support, that is supposedly behind the electron usage of those linux shops.
Also, what exactly are those linux shops, that target multiplatform by using electron? Is it like Cisco? Or Meta? Maybe Bitwarden? Discord? Figma? Microsoft (skype, vscode)?
Rollout of Wayland has not been the smoothest and I think among its major issues is the slow pace of development - it took it 10+ years to become default and certain features present in X11 are still missing. Having said that, after I switched to KDE Plasma 6 with Wayland (on Intel and AMD graphics), I've noted a significant improvement in responsiveness and snappiness of the desktop. I know nothing of how Wayland works, but I assume this is the reason the replacement was needed in the first place. I had to replace my GPU from NVIDIA to AMD, but I don't regret it (all my deep learning compute is on the HPC cluster anyway).
One reason was, that the security model wasn't enough anymore. E.g. every application was trusted and can listen to key inputs e.g. steal passwords and credit card infos. Btw there was an issue that screenshotting in wayland was not possible. But easy in X11 because everything was visible.
Don't know much about the architecture about wayland but I think grahic driver handling changed in wayland too.
>The reason is that everybody has a different workflow, different aesthetic preferences, different ways of doing things
>The worst one is the single UIs for Windows and Macs. There are some ways to customize them but not as heavily as it is possible with Linux.
You're right, and I forgot to touch on this before. Just look at Windows for instance: it's not a monolithic thing, because it's changed over time. Lots of Windows users criticize the new(er) versions, and say that Win7 was the peak of the Windows UI. Lots of people absolutely hated the new "Metro* UI in Win8. So clearly there's no agreement there either, so how could there possibly be broad agreement in Linux?
Desktop managers have never decided if they want to copy Windows or MacOS, both of which are terrible GUIs that we're now stuck with, using paradigms from 1983/1984
They're based on the 1984 technology of "we can barely run 1 application at once", you can barely drag objects between applications, mostly you can't use overlapping windows because of raise on click, which makes dragging anything pointless, they put the menus far from the pointer.
Why when I have my file manager view of a directory open do I need to open it again inside the application to save a file there?
> you can barely drag objects between applications
This works fine on macOS in anything that supports it. For example I can drag assets in and layers out of Pixelmator without any issue, drag emails to the desktop or a Finder to save them, etc.
> mostly you can't use overlapping windows because of raise on click
Which can be disabled if it makes sense for that app. What use case are you thinking of here?
> Why when I have my file manager view of a directory open do I need to open it again inside the application to save a file there?
You can drag a directory into the save dialog to jump to it (Windows gets this wrong), and the title heading of an open Finder window is itself draggable, you don't have to exit the directory if you already have it open.
Alternatively Opt-Cmd-C to copy current directory and then paste it into the save location dialog, or Cmd-Shift-G and paste in the location.
> My use case is I have 2 applications that I want to drag something between, and the windows overlap
This should work for most use cases. If you can see the window for the target app even if you can’t see the drop destination, holding on that window briefly while dragging should raise it to the front (my testing says about 2 seconds). Alternatively (or if you can’t see the target window), the various expose gestures and buttons work during a drag operation. For example on a MacBook you can start dragging from one window, swipe up with your other fingers to reveal all applications or swipe down to reveal just the windows from the current app, and you can drag to the window for your target. From there you can hover on the target and expose will switch to the chosen window after a moment, or you can perform the opposite swipe action while hovering over your target window to raise it to the front.
As for the new document thing if you mean to save a document for the first time by dragging it to a finder window, as far as I can tell you can’t do that. You can drag the finder window to the save dialog but not the other way around.
Unfortunately, I've noticed that non-SW engineers frequently turn their noses up at open-source solutions, and really the entire concept of open-source software, and seem to prefer proprietary solutions, the more expensive the better. I've seen this in the software world too, with embedded systems engineers, though Linux, gcc, etc. has made huge inroads here, though it took decades, and mainly came from the Linux adherents pushing downwards into the embedded space from the desktop space, not from any interest by the existing engineers in the embedded space.
Just look, for instance, at FPGAs: almost all the tooling is proprietary, very expensive, and very buggy too. Or look at PCB design: Altium seems to be the standard here still, despite Kicad having made huge advances and by most accounts being as good or even better. It took decades (Kicad started in 1992) for the FOSS alternatives here to really catch on much, and only really because PCBs became cheap enough for hobbyists to design and construct their own (mainly because of Chinese PCB companies), and because CERN contributed some resources.
I'm not sure what the deal is with engineers hating collaboratively-developed and freely-available software, but it's a real thing in my experience. It's like someone told them that FOSS is "socialism" and they just reflexively dismiss or hate it.
I wonder whether it is a about quality control and completeness.
Pure Software has a lot slack when it comes to delivering incomplete or (in the FOSS world ) even partially incorrect releases. Many issues can be fixed after the fact (even in production) and you can inch closer to a better version as time come goes on.
Mechanical engineering oftentimes can't work that way. An "80% solution machine" usually doesn't work at all and iteration costs (outside of 3d prototyping) can be staggeringly high.
Example: My company produces heavy "things" (20tons+) that have tight tolerances in some places. If the design is off by 2mm because of a CAD bug or unexpected/unknown UI the part could be scrap or require an expensive (read manual) rework.
There go all your software savings.
So why management would love to reduce the staggeringly high costs it's not worth the risk until an alternative is very proven.
In many projects customers contractually require is to use a specific solution.
And even if the software doesn’t cost you in failed projects it can cost you in other ways.
The old meme from 10 years ago about: “Linux being free if your time is free” is largely false for personal usage, but in the corporate environment somebody will have to provide support and with the open source software this is going to be you.
People selling B2B software know that so they will usually price things in a way that it is just a bit cheaper to pay them rather then support and retrain staff.
I’m a software guy. I love FOSS. Much of the tooling that I use is FOSS, and oftentimes the software is as good if not better than the proprietary equivalent.
Until very recently, this was not the case in hardware world. In many cases it’s still not the case. You will meet all sorts of purists here that will tell you FreeCAD is good enough, for instance. Well, I tried using FreeCAD to build a hardware product. And eventually switched to proprietary software because FreeCAD could not satisfy my use case. I made a genuine effort to use the FOSS variant, but it was not usable for me.
I’m more inclined to listen in hardware when someone says the FOSS tools are not good enough after that experience.
FreeCAD moved from "barely usable for hobby projects" to "yeah maybe if I'm really inclined to try it on a very a simple professional project". At least that's what my engineering colleague told me recently.
Which is a massive improvement and the result of many hours of fixing "boring" bugs, improving UX and all the other chores nobody wants to do.
It's because these tools are used to deliver high quality physical products on time and on budget with no scope or interest in messing around with software defects. These tools are treated like physical tools. It's worth paying for a high quality one which won't cause unexpected grief, by people who will provide immediate support because we pay them.
I think if there were good quality open source equivalents they would be considered, but they pose a huge risk, possibly even an existential risk, if they derail our development plans unexpectedly. Paying a lot of money for seriously good quality tools reduces that risk dramatically.
I've had a brief look at FreeCAD, and it's got a lot of potential. But when you compare it with SolidWorks, OnShape or SolidEdge, there's clearly a huge gap in usability and capability which needs closing before a lot of people will be able to consider it seriously. I'm sure it will eventually get there, like KiCAD did, but it will take many years and a lot of investment to get the usability, polish and featureset up to parity. It looks like Ondsel did a really good job to make some progress along that path.
> when you compare it with SolidWorks, OnShape or SolidEdge, there's clearly a huge gap in usability and capability
All 3 of these are using the same geometry kernel - siemens parasolid.
Most open source CAD software is using OCCT (cascade).
It’s the kernel that brings a lot of the capability. Check out “plasticity” (https://www.plasticity.xyz/ ) for an example of a single developers implementation of the parasolid kernel
It's not even a question of 'good' so much as 'the same as everyone else'. CAD drawing pass through a huge number of hands/companies in the process of getting physical goods made, and any slight compatibility problems can turn into huge costs and lots of blame to go around.
It's very much the case that everyone in the supply chain switches over, or nobody does.
I agree although I feel like one could easily make the exact same comments regarding compilers. I can't quite pin down why there would be many free (for various values of free) industry standard compilers but not cad programs.
Because those compilers are mostly sponsored by OS companies to outsource their software development costs in part.
Also notice that all compilers for scenarios where liability is actually imposed, like in physical goods, most compilers are closed source, proprietary, and certified.
Open Source works best for building blocks of software, not for end products. Companies have incentives to share their libraries and tooling, not so much for the final product like a CAD program.
For non-SW engineers, like myself, software is a means, not an end, and FOSS or not FOSS is irrelevant.
To get a EDA tool to a useable condition, and debugged to the point where it is reliable enough to actually use, is just a ton of work. As someone who wants to design circuits, why should I do that work? How will it help me design more circuits? I understand why beginners and casual users don't like them because the EDA tools do have a huge learning curve, but once you're there, they are very productive.
For professional engineers the software license is not really a significant barrier. Compared to the cost of labor, materials and equipment it's basically a noop.
None of the points you make is universally true. FOSS means that there is less of a chance of the rug being pulled from under you in the form of subscription services nobody asked for. This has been a repeated annoyance with one certain company which did that recently for an ECAD tool and an MCAD tool. And, there are enough motivated people who do a ton of work to make FOSS software reliable enough. In fact, MCAD is an exception in that area. We have world class FOSS operating systems, 3D animations systems and development tools in an endless list. Even Blender, which was not very popular a decade ago, suddenly gained recognition. FOSS ECAD is on the way and it will happen some day for FOSS MCAD too. Finally the license cost. The cost of proprietary software - especially engineering and scientific software is exorbitant in countries with better purchase power parity. Much less would happen in those sectors in such places if it weren't for the large repository of FOSS software available to them.
That's their excuse. But I don't want to pay a rent for something that doesn't offer anything new over something I already paid for. I'm okay with paying for news, electricity, water, waste collection or even proprietary software as long as it's one-time. But I don't want to pay a rent to keep using heated seats, security cameras or a software without significant updates. That's just pure rent-seeking. That's legalized extortion in my books. Hence my preference for FOSS software.
I don’t think this is universally applicable. I think you can differentiate software by how important it is.
Some software is at the very core of your business. A CAD, a ECAD, some lab software or a video editing program. Realistically, if you cannot justify the expensive of that software for your business, you probably don’t have a business. Many of those apps require substantial R&D to get right, something you can only afford if you make real money by building it.
But there are other supporting applications that are not as close to your value add as your core apps, but they can still sleep you over real bad if the vendor goes bust or raises prices into the sky. That may be a teams chat app, a mail client, a wiki software. Most of those apps are essentially the infrastructure of any business nowadays and are relatively solved problems. In this area OSS really shines and reduces a lot of the vendor risk.
I get that point, and it's the same in some forms of software development. Take IntelliJ IDEA, it's been around for ages, it's commercial, and it mostly works and thus it's been the default choice for many orgs. But you can't patch it yourself. If anything breaks at your org, you just use another IDE for a week. No big deal.
But that's the thing about open source software you run in production - you don't need one of a dozen enlightened people on the planet who understand it, most often, you will find one on your team who is competent enough to backport a fix, or come up with a fix after debugging it. I see it as more of a safety access hatch.
> Unfortunately, I've noticed that non-SW engineers frequently turn their noses up at open-source solutions, and really the entire concept of open-source software, and seem to prefer proprietary solutions, the more expensive the better.
Well if you're dealing with projects worth 7 figures (or more), it absolutely makes sense to go for a commercial project with SLAs on support. Last thing you want is to hit some showstopper bug, holding up people who earn 4-digit daily compensation, and been told to "figure stuff out yourself".
If you as the author of a FOSS project that isn't a household name already for historical reasons (like, say, OpenSSL or cURL) and you want it being used by anyone else than hobbyists and universities, you won't get around establishing some sort of corporate infrastructure to sell support contracts.
I don't think it's simply "engineers hate open source". Most of the open source tools in the embedded space are just a bit crap. The reality is that good software needs many thousands of hours of development time. The embedded space is actually pretty small in development budget terms - so fewer engineers who might devote time - and also there's less overlap in skillset - electronic design engineers rarely have the software skills required to develop EDA software.
Most of the incredibly well used robust open source packages are sponsored by large tech companies. The embedded space just hasn't had that kind of sponsorship.
I suspect it's the ways in which they are a bit crap. All software is a bit crap one way or another.
FreeCAD's UI is "a bit crap". The "workbench" metaphor is fine as a metaphor, but the specific way the workbenches are put together in FreeCAD is oriented more towards the way the functionality is implemented than what the user wants to do with it. You have no choice but to understand technical implementation details.
That's just one example, but that attitude to UI in FreeCAD is absolutely pervasive.
I think that's a general problem in the space. The user interfaces in general aren't designed, they're an outgrowth of the direct implementation of the underlying functionality.
Yes. You’ll have a hard time finding a full-time professional photographer that hasn’t tried Gimp, and an even harder time finding one that still uses it. That’s not even getting into graphic designers— Gimp’s typography tools are awful. Open source software that’s useable— more recent blender versions, Inkscape, Firefox, Signal— is the only stuff that’s caught on in large part because they deliberately enfranchise designers. As an experienced, art school trained designer with far more than enough full-time coding experience to implement my own designs, I still exclusively contribute code to FOSS projects as a developer. I’ve seen both sides of this and am perpetually dispirited by the dismissive, haughty, and frankly ignorant attitudes towards designers among many developers. FOSS interfaces are put together by and for people who a) have a working mental model of software functioning, so they reason about interfaces differently, b) know more about the code than the problem domain, c) are used to and pride themselves on learning complex systems based on a set of complex docs. Until changes, user-facing FOSS applications will be used by developers no matter how useful they would be to others.
The sad thing is that the current car-crash state of GIMP's UI is what, 15 years after they received the input of a professional HCI designer? In some ways it's improved a great deal in that timespan, and in others it got significantly worse. To this day it lectures you like some bratty kid playing Simon Says if you try to use File -> Save to save a TIFF image. (Complying with my instruction and then telling me why Export would have been better is fine. Recognising and understanding the instruction but refusing to comply with it is not fine.)
> a) have a working mental model of software functioning, so they reason about interfaces differently
You're 100% correct, they do reason about interfaces differently, and thus have wants and needs which are different from those of non-technical users. Those wants and needs are not met by mainstream software, but are met in some OSS software, so it should come as no surprise that such types want to defend that software against the incursion of those who want to make it just like the mainstream offerings!
Like you I have a slightly different perspective here, having been a hobbyist software developer for some years, but having worked in print and design as a day job.
But I still bemoan such things as the awful keyboard handling of the current GTK file dialog, when compared with the old GTK1.2 file dialog. The old one was truly hideous to look at, but handled filtering files by keystroke far better than any current file dialog.
2004: STOP TELLING ME I'M GOING TO LOSE MY LAYERS WHEN SAVING TO JPEG!
Also 2004: HOW DO I RECOVER LAYERS FROM JPEG?
2024: STOP TELLING ME YOU ONLY SAVE TO XCF AND I NEED TO EXPORT TO JPEG!
Also 2024: crickets
I'm not kidding you. That is exactly what I've been witnessing all these years. Project loss complaints went from daily routine to almost zero. But there's a price to pay.
For decades, Adobe has presented a clear text message in the save dialog box and appends a removable _copy to the file name if the format lacks layers/transparency/alpha/animation/CMYK support/the appropriate bit depth, etc. but it doesn't impede professional users' progress when they know what they're doing. It also doesn't change the representation of the document in memory so you can just save a fully-layered version right afterwards unless you manually reload the file from disk.
That approach warns less knowledgeable or hurried users when it looks like they're aiming the gun at their foot, but it still lets expert users follow through unimpeded. Figuring out how to communicate the risk to the user while not removing functionality is proper interface design. Simply not letting people do it is "dumbing it down," and one of many examples of why Gimp is not an appropriate choice for high-volume professional users despite its on-paper feature list.
And I resent the fact that I'm expected to pay that price when I'm not the one who was losing projects.
And as I said, carrying out the instruction but then telling me that I should be using Export instead would be acceptable. Refusing to carry out the instruction, even though the software has identified and understood the instruction just because I failed to say 'Simon Says' is not acceptable.
(Hi, by the way! I think you did some translations for PhotoPrint and CMYKTool some years back?)
Yes, I understand the frustration. The team didn't come up with anything better although maybe they could. I think another suggestion in this thread could very well be posted to GIMP's issue tracker.
Looks like they created a separate gimp-ux repository a few mos ago at least. I'd gladly contribute design work and code there if my experiences would be more collaborative and less painful than they were before I just gave up trying like a decade ago. In my experience, anyone making a design contribution could only do it in a discrete standalone PR-- with gimp's foundational lack of UI design, that's like someone that owns a crumbling dam saying they will only accept proposals to fix individual broken spots because the pieces that are still intact work just fine. The only real options were to make a fork and change it, or... go fork yourself-- and there was no way I was taking on all of that design and coding myself.
Yeah, but trying to contribute design work to FOSS projects sucks— firstly, a whole lot of project maintainers think that UX and UI design hurt usability because they “dumb things down” to make them look pretty. Secondly, the workflows for code and design are completely different — you just can’t break design work down into a long series of modular pull requests like you can with code. I’ve encountered very few maintainers that don’t see that as a fundamental shortcoming of design and designers rather than a plug that needs a different adapter. Either way, you do a ton of upfront work for people that are suspicious of your motives and assume you’re incompetent, and it will either get totally ignored, or rejected out of hand. I’ve contributed somewhere on the order of 5 figures in coding hours to various FOSS projects and have a degree in design, and I still only contribute pure code features to FOSS projects.
I’m quite pleased to see that Gimp has undertaken this commendable step.
> But I still bemoan such things as the awful keyboard handling of the current GTK file dialog, when compared with the old GTK1.2 file dialog. The old one was truly hideous to look at, but handled filtering files by keystroke far better than any current file dialog.
Yeah and I think most UX designers would consider that a bad design though-- developers are users and if it's tough for developers to use, then it needs to be optimized. As someone who's created a few APIs, I know that developing friendly interfaces for developers-- APIs are interfaces that humans need to understand and use-- involves the same blind spots as developing for end users. At first, Microsoft concentrated on developer experience a lot, but I think Apple is probably doing a better job of it now. Their programming environments are products they sell to developers, so they concentrate on making their interfaces smooth(ish) for developers.
Additionally, in the discipline of interface design, the visual polish should be a secondary or tertiary concern. Things like gestalt, implied lines, negative space, and type hierarchy are obviously core tools to orient users, especially in very complex interfaces, but the higher-level look-and-feel stuff is often not even handled by the same people in larger design organizations. Even things those higher-level designers might be concerned with-- interaction designers using the subtlest animations to indicate action or intent, for example-- still meaningfully affect software usability, though.
It's unfortunate that FOSS projects generally just aren't set up to accept design contributions, but it's not anyone's fault, per se. It just isn't the way the standard FOSS organizational structure evolved-- it was basically like a commercial software dev organization but the lead developer was also the product manager. Without a product manager to balance the design and development needs, design will obviously fall to the wayside. Unfortunately, that's left a pretty hostile environment for designers in FOSS. A lot of FOSS developers get defensively arrogant or combative when I even bring it up, but at this point, I'd rather set my beard on fire standing next to a gas pump than go deep into a usability analysis for a great FOSS tool, all of which I'm willing to implement myself, only to have a defensive dunning-kreuger echo chamber of design "expertise" tear my work to shreds without even considering that they might be conflating what they're used to with what's actually good, and they'd almost certainly benefit from change. I get why that happens-- it's just standard social cohesiveness, ego etc. and is not unique to software dev, and it's not their fault that dev culture developed that way.
But even though it's not FOSS maintainers fault, if they want non-technical users to use their software, it's certainly not anybody else's responsibility to enfranchise UI designers into their projects if they care about non-technical user adoption.
> electronic design engineers rarely have the software skills required to develop EDA software.
You could say that about many other fields too, but then why do we have great tools like Blender, Krita, Audacity, etc.? Artists and musicians have great software skills, but electronics engineers don't? There's always been a huge overlap between EE and CS degrees, with "computer engineering" degrees coming about as a merger of the two fields decades ago, so I find this statement hard to believe.
Just a guess, but it could be because the size of EE employers is bimodal. Either you're working for a startup that can't afford to sponsor open source development and would not benefit in time for it to change the chance of success, or you're working for a huge company, big enough to negotiate discounts from the vendors.
> working for a huge company, big enough to negotiate discounts from the vendors.
Google tells me the average salary for a Mechanical Engineer is $95,675/year.
The cost of a single-user SolidWorks Standard license is $2,820/year [1]
You don't need to get big and negotiate a discount - if the engineer says they're 3% more efficient using SolidWorks, it'll pay for itself at list price.
$95k/year is lower middle-class these days in America, and probably strugging to pay the bills in many areas due to ridiculous CoL.
Sure, the company might not blink an eye at spending $2820 on a software license for the engineer to use at work, but the engineer himself probably isn't going to be able to fit that into his own budget if he wants to work on any personal mechanical projects at home.
That's a very interesting question and I'm not really sure what the answer is in general but I can answer for myself.
I'm an EE. I can code. I think I'm pretty good at it. But there's a reason I didn't major in CS, I don't enjoy it all that much and I don't do it as a hobby either.
If you believe that those who contribute to FOSS is a small percentage, then I think for non-SW folks you're looking at a small percentage of a small percentage, which means sparingly few contributors which means sparingly few FOSS EDA tools.
Well, Blender, at least started as commercial software. It was only open sourced after the foundation was put together to hit the source code out of the bankruptcy.
Yes, but Blender at that point was very primitive, both from a features and usability standpoint.
What really drove Blender forward in its earlier years were the open movie projects, both as a way of raising funds for development and as a way of putting the software through its paces to find spots that need improvement. Ton Roosendal has been a superbly skillful project leader in other ways too, like finding the right technical areas and features to focus on, putting the needs of the artists/users first, knowing when to set aside his own vision in favor of what the community wants and not undertaking major rewrites until there is enough momentum behind the project to see them through.
That's a long way in the past though, and one of the fascinating things about the Blender project is the way that they have been able to break with their legacy in a way that other projects seem incapable of. Modern Blender is a very different experience to the early iterations.
>Most of the open source tools in the embedded space are just a bit crap.
Anyone who sincerely thinks GIMP can replace Photoshop or is otherwise good will never understand why professionals eschew open source software when there's work that needs doing.
GIMP is kinda odd insofar as for me (who learned to use Photoshop 25y ago) that it (just like every other tool) just seemed cumbersome and clunky with the shortcuts. I couldn't even use German Photoshop because some shortcuts are different. Some other tools were barely usable for what I tried to do, so I think it's unfair to single out GIMP, although the old multi-windowed interface was just something else.
The functionality wasn't even the biggest problem. And JFTR, I'm not talking about anything that came to Photoshop in the last... 15 years or so, I was just slicing PSDs for table layouts and making wallpapers, not actually editing photos like a pro :P
Yeah, considering how common dual-monitor setups are these days, I'm surprised people haven't revisited the Gimp's UI. Why put everything into a single window when you can put parts of it on the 2nd monitor?
It's interesting to compare Blender and Gimp on this axis. And to a certain degree Emacs and VS Code; or Gnome and KDE; or gcc and clang. It's easy for a certain sort of open source project to get so distracted by the point it is trying to prove that it forgets that it has to actually be good.
The only unfair comparison here is Emacs and VS Code, because their goals are a bit orthogonal. VS Code is meant to be easy but extendable code editor, while Emacs dropped the easy part at least 20 years ago.
"Hard" is subjective, and part of good UI design is reusing visual cues and affordances that the user has already learned elsewhere. A good UI should be discoverable. Emacs is not that. Nor, for that matter, is FreeCAD.
Discoverability is a huge problem in lots of FOSS interfaces. Most end users will read exactly zero lines of dedicated software documentation in their entire lives because they don’t have to, and that is a good thing for end users. I find most developers don’t even notice the great interfaces in their lives. Compare how clunky online shopping was in the 90s with a modern food ordering terminal. How many people learn to use Slack without consulting the manual? Now how about IRC? Keep in mind that slack is vastly more complex, and for many things, uses the same command technique and notation as IRC... slash commands, hash tag channels, etc. The designers knew that was a brilliant part of IRC so they embraced it knowing advanced users would be right at home, and new users had alternatives, but would probably come around to the advanced way of doing things eventually.
One of the reasons chefs rarely have anything to do with cookbooks they write past the initial set of recipes is because it’s really hard to see things from an inexpert perspective. People ask us things like “how long do I cook [something] and we often have no idea how to answer that question. Knowing how much that can change depending on the heat source, initial ingredient temperature, how long it’s been unrefrigerated, the water content of the pieces you’ve got, the shape of the pieces, etc etc etc, we just say “uh, until it’s done?” But it takes a lot of skill and experience to realize when most things you need to cook are done, so recipe developers and cookbook writers do a ton of testing to figure out about how long it takes to get you 80% of the way there and then give some simple ways to approximately gauge doneness in that context. If they’d learn a few simple things that “aren’t that hard”, they’d have precise, bang-on results like I do, every time. But unless you cook the same things so the time, you’d need to repeat that across all of the different cooking scenarios that require specialized knowledge. Chefs run into that because people want us to tell them how to cook things all the time, so the skill gap is apparent, and we see the value in someone who knows how to address that. It was never really shown to me like that as a developer, so I see why so many get stuck in the “come on, it’s not that hard” mindset, generally.
Interface design is conceptually harder, because you need to really consider many skill levels that have different needs. The answer isn’t developers reading some article to “make nicer looking interfaces” or “dumb things down”— which we’ll just piss people off in the end and many of them will be developers assuming it’s an interface designer’s fault. The answer is to deliberately enfranchise designers into the FOSS process to figure out who would benefit from the software, and make an interface that can serve everyone’s needs: inexpert and advanced users alike, if that make sense. You do not have remove advanced functionality to make it useful to non-developer users.
So the first step is to put aside the dev nerd machismo for a minute and recognize that designers serve a crucial purpose that isn’t “dumbing things down” or “making things look nice” and that most developers have no idea how to do it themselves. Once that’s a thing, figuring out how to enfranchise designers into FOSS will be the next step.
>recognize that designers serve a crucial purpose that isn’t “dumbing things down” or “making things look nice” and that most developers have no idea how to do it themselves.
That's true, but also remember that not all designers are actually competent, or in agreement with your preferences. I'm definitely no MS fan, but look for instance at Windows 7, or better yet, Windows Vista: IMO, Vista was the peak for the Windows UI (forget about the performance problems it had at the time): it was pretty, but pretty easy to use most of the time too, with a highly discoverable interface. Now look at modern GNOME, which its backers tell us is created by "UI experts". It reminds me of Scientologists calling themselves "mental health experts". Calling yourself an "expert designer" doesn't make you one, and even any professional field, there's frequently wide disagreement. A lot of design is subjective anyway, so you can't just point to one self-appointed "designer's" opinion and use that as gospel. Even back in MS land, somehow the "experts" went from the highly-attractive Vista UI to the butt-ugly flat UI "Metro" UI in Win8, and that's at the very same company!
The problem is that "UI expert" isn't enough of a specifier. Someone who makes an interface aesthetically pleasing is not necessarily someone who is capable of designing according to known HCI laws. There are absolute truths in UI design, and there are things which, when you spot them, are a massive tell that functionality has taken a back seat.
Moving the start menu from the corner, or otherwise wasting corner or edge space, is one of them.
> That's true, but also remember that not all designers are actually competent,
And not all developers are competent developers, and not all bus drivers are competent bus drivers. That doesn't say anything about the profession itself.
> or in agreement with your preferences.
These things aren't art projects. Using research and testing within your core user bases to remove as much 'preference' as possible is a core tenet of interface design. I see lots of developers scoff at that idea, citing a million popular interfaces that they hate. But, look how many UX Researcher (as opposed to UX Designer) positions there are out there, which usually require a data-focused graduate degree: their entire field is devoted to basing design decision in reality rather than going with the whim of the designer.
Having a working mental model of software changes the way people look at interfaces, and the sorts of interfaces most developers like, most non-developers absolutely hate, so unless the core audience is software developers, it's probably not going to cater to their unusual usage style like FOSS often does. You can design for both. It's a lot more difficult, but if that's your audience, your only other option is to be less useful to some of them. As we can see from adoption, very few end-user-facing FOSS applications get any attention from non-technical users for that exact reason.
> Now look at modern GNOME, which its backers tell us is created by "UI experts".
Last I checked, GNOME was being designed mostly by one guy that didn't have any formal interface design training, but even if they did get a bunch of experts for a later version, it's not like they have carte blanche to make changes. I outright refuse to contribute design work to FOSS projects because you spend 80% of your time justifying your existence and defending every tiny contribution from a ton of misguided technical design criticism from people who don't realize they don't know the technical concepts in design. It's like a bunch of copy-and-paste wordpress plugin 'reviewing' an architectural refactoring by an experienced software engineer based on two minutes of a priori thought experiments and some stuff they read in some articles over the years. Good design always comes from feedback, pushback, and iteration, but that doesn't work if most people involved have no idea what they're talking about. If you asked me to revamp the GNOME UI, I'd run away as fast as I could.
> People ask us things like “how long do I cook [something] and we often have no idea how to answer that question.
Yes. Answers like "until it sounds differently" just cause more questions while being the actual answers. How the hell am I supposed to explain "that different sound". After some time you just start to feel it.
Yeah-- it's genuinely hard. I went to culinary school where we discussed this topic at length and one of my classmates (who already had an English degree) is now the managing editor for a household name recipe website, I worked professionally as a chef, I write professionally now, and aced a college food writing course taught by a long-time head restaurant reviewer for the Boston Globe, and I still have a really hard time writing recipes for people that don't have my knowledge. At first blush, it feels like a trivial task-- just like making interfaces did before I went back to school to study design-- but it requires a lot of specialized knowledge and experience that I don't have.
I get why developers are perplexed by everyone's insistence that designers take the lead in creating interfaces, but leaving Gimp aside to look at another problematic FOSS UX, consider Mastodon: folks around these parts were proudly and rightfully touting Mastodon as an interface for Activity Pub as an amazing piece of software and technological achievement, but incorrectly claiming its UX was polished enough to replace Twitter. When I'd bring up the near impossibility of non-technical users being willing to figure out how federation worked when there are free options, the dismissals were fast and furious "I explained federation to my [toddler/grandmother/nontechnical coworker, etc]: it's not that complicated", "there's a (ten million word) beginner friendly onboarding doc that explains it all." "Users don't even need to know how federation works if they just pick an instance and sign up." I'll bet a lot of friends of developers did a lot of polite smiling and nodding in those weeks, and Opera's Tweets(!) about not being able to find any of her friends on Mastodon was all the evidence you need to prove that most people's most basic use cases-- connecting with and keeping up with friends over the internet-- aren't easily satisfied by Mastodon's UX.
If my Grandparents decided they were going to branch out from "the Face Book" to try that hot new Mastodon a few years ago during the spike, the likelihood of their progressing through the "beginner friendly" wall of text on their onboarding website is about zero. If they did, the first time some mind-bending hentai popped up on their screen, they'd have taken their computer outside and burned it. They would not have taken it as an opportunity to get the prerequisite knowledge they needed to even understand what instance shopping was. My parents would have gotten further, but given how frustrated my engineer father gets with much less confusing ideas because he's used to a whole different sort of technology, I say they'd last about 5 days.
You don't get a much simpler task than making a classical French omelet. It's got three ingredients. I can do it in my sleep now-- it all seems very simple. But it was YEARS after culinary school before I got my perfect omelet success rate past like 70%. Being blind to our existing knowledge is natural. That's a good thing when we're working by ourselves, but it's murder when you're figuring out how someone without it approaches the same problem.
I really think these rants (and italics) are totally unnecessary. Most people see beautiful software every day of the week, and value it.
Having said that, no one owes anyone anything. If Emacs wants to be a power tool, let it. I don't expect a construction crane to be safe and easy for me to operate.
I'm curious: what about the italics, specifically, bothers you? Those are important points or modifiers and italics are a way I draw attention to them.
Everyone takes many of the interfaces they use for granted. I certainly do-- I regularly take my phone's simple, clean mail client for granted despite my first mail client being mutt, but it's really, really clean and gives far more features than mutt ever could. (And a phone is one of the few places I would not prefer using vim style editing.) Having had hundreds of discussions with dozens of developers about interface design, I can assure you that they are no different. It's just that developers often have competing needs in software projects, so it turns into a point of contention. In a regular development organization, the product manager or whoever has the final say. In FOSS projects, the maintainers do. If they're not keenly aware of how much more valuable a good, expertly defined interface brings to a piece of software, they're going to make a worse piece of software, unnecessarily. I've served in both roles professionally and have seen these issues from both sides, many times. An organization controlled by designers would probably be even worse.
So with the amount of shit I've had slung at me when acting as a software designer, I think what I wrote is a pretty measured addition to a conversation that is very important to me. I see most end-user-facing FOSS software getting absolutely no adoption among non-technical users because it sucks for them to use, and I see a lot of developers not entirely sure why that is and coming up with a bunch of folk explanations like "commercial software has advertising" or "their version is dumbed down and looks pretty and end users are dumb and refuse to read docs." I've got important insight into the real reasons why, and as someone that's probably contributed 10k hours of my time to writing FOSS code (admittedly, some of it was paid,) I think I'm entirely justified in sharing it. If you disagree, I'd be interested to hear why, but even if you're not interested in explaining why, I respect your stance on the matter.
I apologize if I bothered you with my wording or even just the what I was expressing (seriously), generally, but I failed to bring attention to these ideas presenting them meekly. The Mastodon situation is exactly the sort of thing I was trying to prevent. Not only did Mastodon repel a giant influx of users with it's usability problems-- big and small-- it gave many, if not most of those users the impression that FOSS software is weird, confusing, and exclusively for nerds, and that's the sort of thing that's going to keep open source alternatives alternative instead of having commercial alternatives to the default, free option.
> Everyone takes many of the interfaces they use for granted.
For example, I've seen many people in the HN comments over the years cite the HN interface as evidence that interfaces are better without designers involved, or something similar. In reality, HN has some of the best interface design out there. It does exactly what it needs to do, simply and intuitively, is much easier to visually orient yourself and navigate than a paged forum discussion, despite being compact it's completely obvious where individual elements begin and end using implied lines, type hierarchy, and gestalt rather than adding a bunch of boxes and lines, works great on multiple screen sizes, needs nearly no documentation beyond policy docs... it's a brilliant, clean, polished interface. It even keenly takes its audience into account-- many end users would be fatigued by the loooong lines of text when you fully expand the window and generally prefer a limited width for text blocks, but users that look at a computer text all day long prefer the flexibility of stretching out the lines horizontally to reduce the vertical footprint and get more on their screen at once. That doesn't just happen-- it was deliberately designed that way. Good interface design is very different from good branding and identity design, or similar-- it should be invisible. The choices should seem natural, or even obvious... but how many sites were set up like HN before HN did it? Compare it to Slashdot, the gold standard when HN got up-and-running. HN is incomparably cleaner and more focused on its core use case, even though it has fewer features and visible controls, which is usually what developers lament the lack of. HN is a great mix between newsgroup/email chain type visuals worked into a forum format, and I hadn't seen anyone else doing that. Many of the interfaces we use that look obviously designed and function poorly were either made by purely visual designers, or developers trying to make something look "designed" and using inspo from dribbbbble or whatever. Beautiful looking is quite distinct from optimally usable, and interface designers generally concentrate almost entirely on the latter.
I'm a hobbyist and over the last month have been improving my 3D modeling chops. Because it's a hobby, the cost of the tools hasn't been an issue. I started with Ondsel, and it looks like a really good tool. I went through a couple of hours of a tutorial, and it looked pretty good.
But then a friend reminded me of the Fusion 360 hobbyist plans, and I decided to give it a try, just to see. It blew my socks off! It's just a lot more refined. The first 12 minute tutorial took me further than I'd gone in the ~2 hours I did with Ondsel.
FreeCAD is an amazing piece of software to be available for free. But in the end Fusion just operated a little more smoothly in lots of little ways. I have really limited time to do 3D modeling, so it's pretty valuable to me to get more done quickly.
One temporary thing that's making FreeCAD a bit hard to get started with is that there's not much content out there for learning 1.0, and sifting through out of date content to find it took some work. That'll improve as time goes on.
That seems like a matter of taste. We switched from Altium to KiCad and I very much prefer it. We don't do any RF stuff, so there might be things that don't quite work in KiCad, but for what we do - power electronics - it works perfectly well.
I wish they kicad footprints were easier to find/modify/maintain.
I modified some its hard to reuse them in other designs. They get saved in places with lots of extra files and I'm not sure how to merge with other designs.
Not what I've heard, and CERN seems to think it's good enough for their particle colliders.
>No open source tooling can even remotely compare in ASIC implementation flow or FPGA implementation.
Yes, FPGA tools are a very different matter. I do wonder if this is really lock-in from vendors more than any preference by users, but still, sufficiently motivated users could reverse-engineer things to try to make a single open-source toolset that works with all vendors' FPGAs. Of course, the feasibility of this is questionable, but we've seen really impressive reverse-engineering efforts in other places in FOSS. Just look at how futile it is for YouTube to try to prevent people from downloading their videos.
Large institutions like CERN run everything. But the advanced stuff is definitely not on KiCAD. It doesn't have support for the right simulation models.
"The CERN physics department is deploying the Cadence analog and digital end-to-end solutions as well as the Cadence verification and Allegro PCB solutions throughout the support of its CERN IT department."
CERN is of course a massive organisation where people use lots of tools. But the annoncemnet you posted is from 2011 and CERN started using KiCad some time later (2014 or so). And there is definitely some advanced stuff they are working on that is done in KiCad such as Macbeth [1]
They also have a service contract with KiCad Services Corporation. [2]
That sounds nice, but I haven't seen any of those features drop yet... I wouldn't be surprised if altium can do simulations, but it's not exactly a free/OSS product.
Almost all the tooling in FPGAs is proprietary because the vendors don't provide the information needed to develop open source tools around them. They'll also often obsfucate the bitstreams to make the reverse engineering process more difficult. Progress is being made but it is a slow and painstaking process.
This doesn't really explain any hostility towards open tools but it does explain much of the preference for certain well established commercial packages:
The commercial software vendors do a great job of marketing to engineering schools and students. Once you learn some software it's a lot of work to relearn. So if you get people accustomed to your proprietary ecosystem early in their schooling and during the start of the career, you have pretty much hooked them for life.
If that were the case, most of the (academic) software world would still run on Matlab and Borland. Instead, Python has completely taken over that space even without salespeople to push it.
Most of the open source CAD stuff is just Not That Good.
If I have two solutions I don't expect to easily work, one is free and one comes with an expensive support contact, then I will weigh the cost of the support against the value of the whole project.
Often the support is worth it, because I can have a conversation with someone early in the process.
If I commit to open source then I either need to hire an expert (this does not get the same guarantee as a support contract) or live with much more uncertainty.
>I've noticed that non-SW engineers frequently turn their noses up at open-source solutions
The problem is that usually open source solutions are really, really rough around the edges from UX perspective - and it could be minor edge cases for programmer! - but for engineer they are a dealbreakers.
Look at it from the engineer PoV - they could learn industry standard CAD solution that works, has relatively good(depending who you ask and which version they started with) UI/UX .. and it's something they employer pays for.
I worked with civil engineers that tried multiple different 2D CAD software packages and frankly, all of them hate Autodesk as a company, but they still did pick AutoCAD. They did have different preferences for specific AutoCAD version though.
Honestly the core problem is that there's no pressure from clients on open source software to have a good UX, because there are no clients - just users and developers.
The other problem is that sometimes from the perspective of an experienced user, "good UX" means "works exactly like the piece of software I've been using on a daily basis for the last 15 years."
Even if a brand new UI is objectively better, to someone who's invested thousands of hours in becoming fluent, fast and efficient with an existing UI (however quirky or obtuse it might be) the new UI will be an impediment to productivity.
> Unfortunately, I've noticed that non-SW engineers frequently turn their noses up at open-source solutions, and really the entire concept of open-source software, and seem to prefer proprietary solutions, the more expensive the better.
Probably because if you complain about bugs or problems in open-source software, a legion of trolls comes to tell you "erm, it's open source, you can just implement it yourself" no matter how skilled the user is at programming.
Like, for example, the lead dev of Inkscape, who used to (not sure if he still does) go around on twitter looking up complaints about how slow Inkscape is on macOS and then complain about them being entitled.
No wonder they don't want to use it, then, if it's considered rude to even expect the software to work.
Yeah, this is a non-trivial effect. It affects FreeCAD too. Mostly contained to the forums, but if you ask a question it's wise to give people who actually know what they're talking about a couple of days to show up.
I think part of it is also the user knowing that they have no right to express frustration when the product is free. That's actually a mental burden. In a sense, people buy software partly so they feel they have the right to complain when it has issues. And honestly I think that's pretty reasonable
No, they do have the right to express frustration. What they don't have is the right to demand work from anyone else, but what tends to happen is that communities are on such a hair trigger for the latter that they reject the former even when the frustration is directly caused by a solvable problem.
In the case of FPGAs it doesn't really matter that the proprietary tools are buggy. What matters is the features and utility they have. Open-source FPGA design is still extremely, extremely far behind the proprietary alternatives in many dimensions (power support, integration tools, many aspects of simulation and test, general tools like floorplanners, and so on.) That isn't because people aren't trying either. It's just really hard and has limited talent pool.
I've spent a lot of time at this point with both toolkits. I use the open source tooling extensively for my own designs. But you tell some grizzled RTL person there's no power analyzer or native SDC support or that UTM was only recently supported in some simulator, and they're going to laugh at you. They've been doing that stuff for 20 years. I know this because I've done it several times (though other people find particular things, like free RTL verification tools, much appreciated.)
I think FOSS/software people paint some very rose-tinted picture in their mind where the mere availability of something for $0 would make it an obvious choice, even at only 10% of the functionality. But that's not how people see it in reality. Many people, including engineers, think of it the other way: if it's so good, why is it $0 and how do I know it will keep being developed? They've made their peace with the fact that the $5000 tool will exist practically for as long as they need, get the job done, and be supported.
With respect to cad suites it's push from the top. That starts at education where sweet deals are made to force students to use one specific suite while it should not matter what you use.
I'd frame it as: people who want to get stuff done and who can't or don't want to have to fight or troubleshoot their software or the system it runs on will often have to choose non-open-source options.
Some examples, from my perspective of being an enthusiastic and reasonably tech-savvy hobbyist:
* Linux is almost always a huge pain to get running well. In contrast, MacOS almost always just works, and while Windows can be a bit more janky, it very rarely needs countless hours spent on e.g. Ubuntu forums or Stackoverflow trying random fixes until one does (or doesn't) work. Of course there are reasons for this, but it is true. (Will next year be the year of Linux on the desktop?)
* Python is something I fundamentally love and use frequently, but I'm not the first to notice the terrible UX when it comes to managing different versions of Python itself, and its packages. Note that virtually every Python-based project on Gibhub (which is lots, thanks to ML) comes with a different set of instructions to get it running, usually based on a different distribution or package manager, thanks to an n+1 problem-solving approach [0] from the Python community. You can often run into huge issues simply installing a single popular package (looking at you, OpenCV).
* FreeCAD... I'm an enthusiastic mid-level CADder, and have used several different commercial packages without a problem. FreeCAD is just awful currently - fundamental issues/incompatibilities betewen the different modules within the base system, a terrible ugly UI, an unncecssarily steep learning curve (even for someone well-versed in CAD). And of course the answers to (some of) these problems are suited to the limux hacker - "oh just install so-and-so's fork instead". Really? And you're surprised it doesn't take off with the hobbyist community?
* Dearpygui.. a lovely, performant GUI for Python, but with such terrible documentation that for anything beyond the (sparse) examples, you have to resort to asking questions on Discord. (They are reponsive and friendly, though.)
* GIMP - powerful... and just crappy to use.
My basic premise is that most open-source products are designed and coded by hardcore programmers/Linux experts, who are great coders but either don't care about or don't have skills in optimising UI/UX/usability. Maybe it's the much-derided product managers (i.e. not hardcore programmers/Linux experts) who bring usability to a project. Maybe open source needs to work on attracting non-coders to its projects, and be open to listening to their criticism?
> Python is something I fundamentally love and use frequently, but I'm not the first to notice the terrible UX when it comes to managing different versions of Python itself, and its packages.
Python’s ecosystem looks like a trash fire and sits along nicely with JavaScript (they burn brightly in subtly different ways).
Neither are concerned with adoption at this point though.
> Maybe open source needs to work on attracting non-coders to its projects
I think Python is proof that the economic realities are more nuanced than this.
Even in particle/astrophysics we rely on proprietary FPGA Vendor tools, in proprietary electronics design tools (ok, kicad is seeing increasing adoption), and often proprietary embedded tools (depending on the microcontroller vendor). Not to mention proprietary graphics drivers (CUDA), CAD tools (Solidworks, Solidedge), mechanical or e&m simulation (comsol, Ansys, xfdtd, wipl-d, etc). A fair number of people use IDL or Matlab too and mathematica is pervasive among theorists. Probably nobody uses Origin
anymore. We've gone backwards on documents since everybody is using overleaf now. It's true most of the software we develop, if made public, is open source.
Yes there are still pockets of proprietary tools but is of limited usage. Most of people in the field is not going to use them (because they don't work on these things). And most of these tools are tied to the hardware and there is increasing adoption like you said for kicad and FreeCAD. There are two exceptions which are theorists love for Mathematica and CUDA for GPU programming on NVIDIA GPUs. For CUDA, it is not bad as you don't pay per usage or don't have contacts, you do this because you purchased NVIDIA GPUs. Which is the best in the world for the use case we have in particle physics experiments. I have never seen someone in the HEP community or Astrophysics using Matlab.
Regarding overleaf, it is open source and you can self-host the community edition for free or self-host professional instance and pay subscription.
Matlab users certainly exist, though they are much rarer than 15-20 years ago (before python was a suitable alternative). For signal processing, matlab still has has advantages over e.g. scipy.signal, which has not yet reimplemented all matlab functionality.
I didn't realize Overleaf was open source (or at least open core...)
And FreeCAD can't yet even effectively render many of the parts for my experiments :(
I was talking about particle physics and HEP in general as this is my field. Not many people do signal processing so it is small pocket as I said and some are using scipy just fine.
Overleaf is open source for all purposes. this does not mean you have to use all features for free selfhosted. it has to get some money. The decision by CERN to provide professional account for all CERN users on overleaf.com instead of self-hosting one has to do with minimizing unnecessary deployment and maintenance (including security) burden. I guess also they got a good discount from overleaf folks.
I'm not saying that there is complete independence now. but for most people in the field and most purposes, you can rely on open source tools and it will work and you call it a day. CERN is not the business of designing GPUs to compete with NVIDIA (Although it will be good).
and FreeCAD seemed simultaneously the most ambitious, and the most promising --- hopefully v1.0 will pay off on that, and result in a tool which can be used widely --- but it will eventually need some sort of commercial support. Ondsel seemed a good fit for that, and it's unfortunate that they didn't make it.
Notable other options include:
- Solvespace --- a venerable and simple tool, it is barebones to the extent that many folks won't be able to accept it
- BRL-CAD --- _the_ venerable choice, but the interface is so old school and programming-like, most folks won't even consider it
- OpenSCAD --- 3D modeling for programmers --- the great thing about it is, anything which one can describe mathematically can be modeled --- the awful thing about it is, what one can model is limited by one's mathematical knowledge. A further concern is that DXFs from it are just polylines, no arcs --- I've been working to address that using OpenPythonSCAD at: https://github.com/WillAdams/gcodepreview
LibreCAD is workable for 2D, though I only use it for file conversion.
The other notable options are OnShape (free for public designs), Alibre (quite affordable), Solidworks for Makers (for values which include non-commercial usage watermarking).
OpenSCAD is my go-to. It's self-contained and AI coding tools know the syntax well enough to help you move fast. Unfortunately I keep hitting a complexity ceiling.
If it doesn't like how I'm describing something, it crashes. I have to load an older version of my .scad and try a new approach. This usually happens 70% of the way into a complex project, which is quite discouraging.
The Python ecosystem has CadQuery[0] and a few other tools built around the Open Cascade kernel[1] which is quite good in my limited experience. CadQuery is positioned as an OpenSCAD alternative [2], and I really want it to be. Unfortunately the user experience isn't there yet.
Making an object with CadQuery is writing a Python program. Which means you need a Python environment and dev setup. CQ-editor [3] is nice, but needs a Python environment first. I think CadQuery would be much more viable OpenSCAD alternative if it was packaged into a standalone CQ-editor application and published via homebrew, etc.
I'm also interest in Zoo [4](fka KittyCAD). They're trying to create a modelling tool that combines model-by-code and model-by-mouse. With some AI layered on top. They have an interesting architecture where they stream geometry to your local device from the cloud. Should be great for performance, but ties you to the cloud.
If you want 3D in Python with OpenSCAD syntax try: https://pythonscad.org/ --- I've been using it, and the developer has been amazing at fixing bugs and churning out features.
The KittyCAD stuff seems almost perfect --- will definitely be looking more closely at it
This is a huge shame. Ondsel brought much-needed focus to the freecad development process.
I hope that with them gone the project doesn't revert to the mindset of "everyone gets their own fiefdom (workbench) to manage" that's resulted in instabilities and fractured user experience in the past.
It's sad that this is failing, and sadder still that I, an occasional CAD user, never heard of it even though I really wanted something like this (at least in theory).
I've just started using FreeCAD after bouncing around Solidworks, Onshape and Fusion360. The changes in 1.0 are more than welcome! Thank you for your contributions!
I learned freecad some years but never really liked it. Fast forward to version 1.0, it feels like a huge improvement and I think k I will try to use it again for smaller projects.
The biggest improvement IMO was the partial sketch thing, which I can't even find among the release notes...
It is! It is totally usable for my hobby projects that I overkilled with Fusion360. Btw Fusion 360 crashes as often as FreeCAD 1.0 for me, despite its holier-than-thou maker.
Zoo and openSCAD both create 3D objects using code in a domain specific language. Other than that, very different. OpenSCAD has limited ambitions; Zoo wants to kill Autodesk.
Zoo is building a commercial grade product suite from first principles. They're writing a new geometry kernel and optimizing it for GPUs. They wrote a new domain specific language for CAD [0]. They're running the kernel on the cloud behind an API, streaming video to the client and billing by the server-minute. Ideally that will deliver great performance and keep the tool accessible to casual users.
The really exciting thing, for me anyway, is they want to unify design-by-code, design-by-mouse, and design-by-ai. Start with a plain language description of what you want. Get a fully parametric object on your screen. Click around making adjustments. Pull up the code and make precise changes. Keep a complete changelog in git.
> They're running the kernel on the cloud behind an API, streaming video to the client and billing by the server-minute.
That sounds absolutely horrible though. There is no chance of it being truly free because the servers cost money. You are fully locked-in in that system. It won't work offline. You can't use it for secret projects...
Unless it's intended for companies to run the API on their own servers?
I have a project that turns Blender into something like Tinkercad. I want help with some Blender gurus though. I made it for my wife because once her designs get too complex Tinkercad servers crash and stop exporting.
Ignoring the entertainment industry, if there were no copyright for software applications beyond that which can be achieved by contract, what would the CAD software landscape be like? Clearly it would exist, but with a completely different revenue model. Predictions?
Unfortunate but extremely predictable. The commercial market for CAD cares about CAD that actually works, not free software ideals. FreeCAD is simply not in the same league as commercial CAD like Solidworks, NX, Creo, etc. IMO it's not even in the same league as SolveSpace, at least last time I used it (which was admittedly some years ago).
Blender suffered the same sort of issues as FreeCAD does, but managed to get out of the slump.
It is often important to have a main player enforcing proper, unified UI/UX and fix the many small problems and bugs which drive users away.
Sadly it is usually an issue with long running and highly complex open source software that it gets really fragmented.
You see that in every function having its own button or workspace, inconsistent naming, functions which do the same but slightly different and things working differently depending on some context where they really should not.
Thanks to the people from Ondsel it felt like FreeCad would be on a similar route to Blender.
It was way more user friendly thankfully there has been major back porting.
So there has been a lot of progress especially with the upcoming 1.0. You should give one of the Release Candidates a try.
I use it for my 3D printing projects and it works pretty well.
The parent comment rephrased: 'oh it was a useless effort like any other effort to push open source in CAD'. (Not true btw, Blender is an institution in non-parametric design, the niche for open-source is just for parametric CAD).
How is open source supposed to break through to this 'market' as you call it? Should we just give up instead?
Blender is a great success story, but even that started from a commercial codebase. Even Blender, which is aimed at artists, had a pretty awful UX for a long time. It only got tooltips relatively recently.
I think the UX situation is even worse in open source CAD and EDA because they're written by... you know. Kicad and Geda have abysmal UX. Only recently have we got Horizon that is pretty good.
The only open source CAD software I've seen that is in any way remotely usable is SolveSpace. It's actually quite good but it has a few big limitations:
* No bevels or fillets
* Small holes become diamonds; I'm not sure why but apparently it was quite hard to have an angular precision for some reason
* The UI is quite odd; some custom toolkit.
IMO if you switched it to Qt, fixed the other two issues, and spent some effort promoting it (it seems to be relatively unknown for some reason) that would go a loooong way towards "good CAD". Hopefully it would take mindshare away from FreeCAD which is just giving open source CAD a bad name.
reply