>I think especially since the UI overhaul in Blender 2.8 the project has been on a steep upwards trajectory.

100% agreed. I know a lot of people don't like that but sometimes I feel that FOSS projects are intentionally sabotaging themselves by ignoring industry standard options/conventions and instead they are following open source ideas just to be different. UI/UX is the main symptom of that. Blender could move forward and wish others could too.

Krita is another example of a good project

CAD is the next frontier where we need a "Blender moment"

▲

BadBadJellyBean 17 hours ago | parent | next [-]

We have to keep in mind though that many open source projects started as something that someone wanted and then made. It probably worked just like that person wanted and then it grew. Maybe it is because they weren't too versed in UI/UX design.

Another thing is that many classic open source projects don't have a "I want to grow my user base" mindset. Why would they. It's not like they get paid.

Big overhauls also always have the risk of alienating current users. I learned Blender on the pre 2.8 UI and because I use it rarely I still sometimes struggle with the new shortcuts.

Blender clearly benefited from the change but the real spirit of open source is: you don't like it then help fix it.

▲

Kye 13 hours ago | parent [-]

There always seems to be an incompatibility between the people who made it, the people who use it, and the people who want to contribute. The latter two often try, but the former isn't interested in the help or has a very specific vision for the project and doesn't allow any input that isn't in line with that even if it's not in conflict.

It's hard to fault anyone in that triad 100%. Open source has a way of becoming infrastructure. People come to depend on tools made by people without the resources, interest, or personality to run an infrastructure project, or who won't budge on their vision to allow contributions outside of it that might help get the project to a point where it can attract enough vision-aligned contributors.

Forking potentially shifts the problem to a new triad, so it's not an obvious solution in all cases.

	▲	crote 8 hours ago \| parent [-]
		> the former isn't interested in the help or has a very specific vision for the project and doesn't allow any input that isn't in line with that I've come to call this "fenceware": technically open source due to its licensing, but community-wise it is as if the developers just throw a ball of code over the fence every few months. Sure, they let you play with it for a bit, but it is not yours to co-own.

▲

panarchy 13 hours ago | parent | prev [-]

The problem with (3D) CAD I've heard is that the Open CASCADE CAD kernel is a huge mess. So as much as they update and fix FreeCAD (and they've made a lot of good progress, but it's still very rough around the edges) they're always going to be hampered by that. And making a new CAD kernel is a massive undertaking.

▲

crote 8 hours ago | parent | next [-]

While this is definitely true, for a long time FreeCAD hasn't exactly made it a high priority to properly work around that.

For example, the Topological Naming Problem (as I understand it) is made quite bad due to OpenCASCADE design - but as we've seen with 0.19 and later it is possible in a lot of cases to work around that. But that's a lot of really hard work with relatively little reward, so for years it languished on the backlog, and users had to deal with even trivial designs randomly blowing up in their face for no clear reason.

The result is a CAD program filled with footguns. Nobody wants to address structural issues, so you just pretend they don't exist, hide a half-baked tutorial on a Wiki on how to work around the worst of them, and blame the user for holding it wrong.

Commercial applications can solve this by shoveling copious amounts of cash at any skilled developer who is able to make any real-world improvement - even when it's not a perfect solution yet. FLOSS applications have to wait for a developer to come around who is masochistic enough to tackle it for free.

▲

wincy 13 hours ago | parent | prev [-]

Question for someone who is very far away from this kind of development - why does CAD software need a kernel that’s wholly separate from the UI? Why aren’t they the same thing? I just don’t understand the abstraction that necessitates writing the software this way.

	▲	duffmancd 8 hours ago \| parent \| next [-]
		It is much like a game might use a physics engine, or a new language might use the LLVM backend. To overly simplify, a CAD kernel will keep a list of operations (make a cube of this size here, drill a hole of this depth here, round these edges but not those). And combine that into a final volume. These responsibilities only get more and more complex as a part gets more complex - so using a pre-built engine allows CAD software to focus on tools and workflows to translate human instructions into lower-layer kernel geometry: the UI/UX. It also crosses into compatibility, if you use the same Kernel as another CAD it is much simpler to export/import from them. Otherwise you would have to reimplement their kernel (or enough of it), or be stuck exporting triangulated versions of the final volume - sort of like converting an image from vector to raster.
	▲	crote 8 hours ago \| parent \| prev [-]
		Same reason a browser uses a separate library for image decoding, or font rendering. A CAD kernel is a very complicated piece of heavily specialized math. The UI itself is there to let the user construct the input data for the CAD kernel and to display the resulting output. Doing that translation in a user-friendly way is already hard enough without having the kernel smeared out all over the rest of the application.