Sure, but if experimental physics don't matter, wouldn't it be a far better idea to develop all those kinds of technology without actually building the expensive collider itself?
You could use the same argument to justify spending $1B on searching for the Loch Ness Monster. The problem is, you can only spend money once. If you're spending $1B on the FCC you aren't spending that same $1B on all kinds of other research.
With the LHC there was a very clear goal: verify the Standard Model and prove (or disprove) the existence of the Higgs boson - and hopefully discover some unexpected stuff along the way. On the other hand, the FCC is mainly a shot in the dark: they aren't validating a widely-accepted theory, they are just hoping that if you spend enough money on a bigger collider something interesting will fall out.
Most research gives you at least some insight. With the FCC there is a very real possibility that the insight will be "our $20B collider found absolutely nothing, now give us $1T to build an even bigger one". Sure, funding research is a long shot, but at a certain point you're just setting money on fire.
I see your point, but thats a really bad comparison. We are pretty certain that there is no giant dinosaur in a lake, but in terms of fundamental research there is a lot we cannot really explain a great many things. We dont even know if we are "looking" correctly, with the right concept in mind.
I agree that money spending must be carefully considered, but for this research there really is no replacement. You can shuffle public spending around, but an Experiment not dont will explain no part of the Universe. If the countries and Supranationals that are able to dont fund them we will be stuck with what we know now until they do.
It is a lot of money, but it is also the only way. Does that meaningfully stop the EU and all others from doing their thing? I would argue no. We can still afford it and so we should.
I'm definitely one of those strictly-programming people.
Sure, I can probably hack together a sorta-kinda technically-usable UI, but I know I'm awful at it. In my professional life I quite early on realized any attempt on my side is just a waste of time and effort, so these days as a mostly-backend developer I don't go beyond sticking bare unstyled HTML elements on a page to demonstrate basic functionality. I'll leave all the design stuff to the people who are actually good at it!
It's not that hard though to make a drastic improvement over that. Basic CSS isn't complicated. Sure, there's quirky things, but it's still possible. As "over the weekend" type of projects, I have taken websites/apps with UIs that I've thought were interesting and recreated them with HTML/CSS. You learn a lot very quickly, and then your UIs start to suck a lot less. It's still coding as far as writing in and IDE and testing/fixing bugs. You just get to skip the compiling part of it!
Version 5 was kinda-sorta usable - but buggy and painful. In practice everyone would tell you to just download the nightly build of version 6 instead, as the UX improvements were massive. It became a genuine joy to use, and with the death of EAGLE the no-brainer choice for every hobbyist.
Since then development has raced ahead, with regularly scheduled released chock-full of both small quality-of-life improvements and new features focused on professional use. It's still a tier behind the likes of Altium, but these days KiCad is a very solid choice for everything but the most high-end PCBs.
It is definitely good enough to build your small consumer business electronics business around, which means there are suddenly a lot of potential users willing to throw a few bucks at it to solve the remaining small papercuts and missing features they run into.
Some complexity is of course an inherent part of the domain, and you can never truly get around it. At best you can stick to sensible defaults for the basic user and initially hide the most complicated parts until they are needed.
On the other hand: there is no reason whatsoever something as trivial as drawing a circle has to be as complicated as launching a rocket in GIMP. It certainly doesn't lack the technological scaffolding, and UX-wise people would already be ecstatic if they just cloned how 30-year-old version of Microsoft Paint did it. So why doesn't it have a Circle Tool yet, despite the massive amount of requests for it? The only possible explanation left seems to be an active disdain towards basic non-technical people: the UI is hard to use because they want it to be hard to use.
> 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.
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.
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.
For the same reason Maya & friends offer heavily discounted (or even free) educational licenses: people tend to stick with what they initially learned.
That approach works great when someone's first experience is in a traditional education system, but these days any interested kid will start to explore the options way before that - and all those self-taught hobbyist Youtube teachers haven't been offered free licenses to make content either!
So now you've got a decent pool of enthusiastic kids flowing into education with pre-existing Blender knowledge. And Blender is good enough for educational purposes, so as long as it doesn't significantly hamper the students post-education it is very attractive for educators to adopt as well - why bother with all the hassle of getting educational licenses when you can just download it for free?
The second Blender started to get industry adoption it was basically over for Maya. They could've saved it by turning it into a freemium product which hobbyists can download and install as easy as Blender, but it's probably too late for that now.
> The second Blender started to get industry adoption it was basically over for Maya. They could've saved it by turning it into a freemium product which hobbyists can download and install as easy as Blender, but it's probably too late for that now.
I was with you up until this part. I was a DVD programmer for years on the de facto standard software which was very expensive and cumbersome for some people to use. Then Apple released DVD Studio Pro which did a lot of abstraction layer simplification for people, but also meant that something could not be done in that software that could be on the big boy package. I know it's an apple/orange situation, but there are times where there's a reason for the cheaper/free price tag. I haven't paid attention to the capabilities of Maya/Blender for nearly a decade, but I'm guessing there are still things that can be done in Maya that cannot be done in Blender.
It's a self-reinforcing loop. Once a FLOSS tool becomes good enough, it'll start to attract professional users, who are willing to invest in it, which makes it even better. And it is quite hard for commercial players to compete with free.
But FLOSS software is mainly made by developers. Who like writing new flashy features, but are awful at UX, and making sure all the small kinks are worked out.
So most FLOSS software gets stuck in a "death by a thousand papercuts" scenario, where it has enough features to technically be usable but it is painful enough to use that no professional would ever adopt it.
Blender got out of it. I really hope more projects will follow their example.
For those of us who've used microsoft teams, jira, servicenow, salesforce, or basically any insanely popular (in the commercial if not upvote sense) products, it's unclear what is being compared to with these tired claims.
"Bad" comes in many shapes and sizes. Specifically, "technically competent person implementing a thing designed by a technically incompetent person" is remarkably different from "technically incompetent person implementing a thing designed by a technically competent person".
The way this plays out in practice is that those products you listed can hire actual UX designers, but many product decisions are made by people focusing on business concerns rather than product concerns, so you have competent people implementing designs by incompetent people.
Inversely, because open source software is usually built by people trying to scratch their own itches, they those people actually understand what the product should be, but, because they're usually software engineers instead of UX designers, they're typically incompetent at UX design. So you have incompetent people (devs with their UX design hat on) implementing designs by competent people (those same devs, with their "scratch my own itch" product owner hat on)
No, it isn't. Lots of non-trivial OSS desktop applications are clearly made by people with no interest in aligning with expected desktop GUI behavior. From Gimp with dozens of windows to LibreOffice which is slow and has bad font rendering. And those are the 'poster apps' for FOSS desktops, lots of apps are worse.
Gimp's single window mode was made the default years ago now, so that's not a great example anymore - there's scientific software that uses that paradigm that might work better, but most of that isn't OSS. Also, Libreoffice being slow and having bad font rendering seems pretty inline with Word nowadays...
The best way to draw a circle in gimp is still the awkward select -> foreground fill workflow. At this point this example is beating a dead horse, but the horse shall continue to be beaten until a proper ellipse tool is added.
Depends on your system. A few years ago I ran it on a MacBook where scrolling on an empty page took ages. Seems nobody tried it out on a Mac before releasing the port since it was totally unusable. Hopefully it's fixed now, but I wouldn't recommend a piece of software I don't trust to anyone.
These are all products the ux direction of which is likely influenced more by corporate power dynamics. Sure, uxers are involved, the real power they have is a different question.
Everyone’s got their preferences, quality of ux is by definition subjective. That is what makes these discussions hard. Naming any examples will always have ”nah i don’t like that product” as counterpoint.
An equally weird trope us UX practitioners dumbing down UIs. It simply depends on who we are designing for.
As soon as developers actively hang out with real users in real life and genuinely observe them without intervening, i’m all for oss projects without uxers.
I’m definitely going to read those, but even without doing so “inviting the users” as a concept carries a lot of potential. We were tasked to rewrite a very old windows app for backend grocery store sales in a web/Laravel/Vue application, and product spent _months_ if not longer sitting with sales reps, watching them use the old tool, and asking them what they would want to see - how does it work? Can it be more efficient? What do you dread most when using this?
The end result was a real pleasure both to write and to use.
>As soon as developers actively hang out with real users in real life and genuinely observe them without intervening, i’m all for oss projects without uxers.
Game dev here. Play tests are excruciatingly painful. Spend some time showing off a game and you can see why so much ux these days are "boring" and samey. Deviating off the beaten road takes so much extra polish compared to seeing how competition controls work and copying that.
Microsoft Teams was bad, so they rebuilt it and somehow made it worse. Then they decided to do the same with other apps, like Notepad. I switched to Ubuntu on my computer this week. Linux administration is not something I want to spend time on, but LLMs are able to help me debug why my password manager can't talk to my browser and write shell scripts to fix it... I'm able to focus on work and be done with the Microslop.
Nobody wants to use those products either; they just exist because their default at a certain scale, or they're effectively free because they're included in your existing MS license.
For GIMP the comparison would be either Adobe stuff or what used to be Affinity products. Libreoffice is now competing maybe with MS Word but probably more often Google Docs or Markdown editors.
Old blender used to have a very technical UI; a cacophony of dropdowns and small text that functioned but was quite overwhelming. Meanwhile things like SketchUp became popular because they weren't as powerful necessarily, but were very welcoming, and that's hard to do with a complex offering.
It looks like you only use a tiny fraction of Teams' functionality. I agree, there's little to complain about when using it for IM/voice/video calls. When you start using it for other things, especially the enterprise features, it is bad. It is a resource hog, handles navigation poorly, has poor default settings, finding installed apps can be tough, etc.
My current pet peeve: I’m often going back to the previous week on Monday to fill out my time sheet. So, I open the chat for a meeting last week to see how long it took, fill it out, and hit the calendar icon in teams and I’m back on the current week. It’s a painful UX flow that I’ve now built in to my brain, so help me god if they fix it.
Note that teams does include a “back” button, and also note that it doesn’t give a flip about state - it knows you were just at the calendar but doesn’t care where, so you’re back on the current week
Lots of that is momentum and politicking. Or the result of decades of concerted effort to associate your product with it's niche, from education to industry, like Adobe
>it's unclear what is being compared to with these tired claims.
Relatively good UX. Because Microsoft, Salesforce, etc. Have full time teams of designers in tow. For historical reasons it's harder to get said designers to work on FLOSS.
Getting good UX requires professional designers, extensive human testing, and knowledge of human psychology—things historically in short supply among the OSS geek set. In the 1980s Apple ran a human factors lab that spent thousands of hours determining which interface features were the easiest to use and most efficient for many common computing tasks. This is why classic Mac OS is still the gold standard for UX. Even Mac OS X started making compromises to accommodate techie trends, rather than keeping the focus on the average user.
Because much proprietary software has garbo UX, that doesn't make the OSS UX situation not garbo.
I think the blender secret sauce is their artistic projects.
Put a bunch of artists in the same room as the developers and have them produce a work.
It ferments this amazing combination of aggressive QA testing(the artists) and top tier technical support(the developers) while focusing on real problems(the work) that really brings out the best possible product. The GIMP project would probably be better off if they invested in a couple of rounds of this.
I think blender always had an amazing, ahead of it's time interface. It did lean overly hard on knowing the hot keys, probably a product of it being an in house tool but the opensource versions have worn a lot of those rough edges off(menus to provide clues) while keeping that same super smooth workflow core.
>It ferments this amazing combination of aggressive QA testing(the artists) and top tier technical support(the developers) while focusing on real problems(the work) that really brings out the best possible product.
Devs stil run the show, and it can be a huge effort to convince them to change course on something. People were complaining about the mouse controls for years and it took until 2.8 to finally convince the org otherwise to adapt a more typical workflow.
It's a rough balance because the other extreme is artists making unrealistic demands based on how the system is architected (or worse, the deceptively simole: https://xkcd.com/1425/). So I don't really have a solution.
Part of what makes this so much of an issue is that in FOSS projects, the things that get worked on tend to either be low-hanging fruit and/or a personal peeve of one of the engineers. Everything else is at high risk of falling through the cracks and being ignored or forgotten.
It’s kind of the open source counterpart of how in proprietary software, some types of bugs tend to get perpetually kicked down the road to make room for development of features that are perceived to be of higher likelihood of increasing revenue.
In theory, FOSS projects have more agency to correct this class of problem than their proprietary analogues do because they’re not subject to the same economic pressures. This however requires leadership with a strong vision for the project and soft skills to unify and motivate contributors to work on not-so-sexy bits, and this type of individual is rare in that space.
> But FLOSS software is mainly made by developers. Who like writing new flashy features, but are awful at UX, and making sure all the small kinks are worked out.
That is what product managers are for; someone to lead the product's direction, ensure quality control, and to instill taste. That requires being able to say when a feature is poorly implemented or outright bad and unnecessary -- it's not always just kinks. The problem is that this collides with the collaborative ethos of open source software. But when it's not done it's the users who suffer.
FLOSS software is often made people who are interested in the thing being done. The UI to do it is something that can be fixed "later". But later is always later. There's always another feature to implement before you can sit down and really fix that UI.
And then by the time they do get around to fixing the UI it seems the codebase is horribly bloated and littered with tech debt and now updating the UI would basically require a whole application rewrite. Which I have seen happen and work, but I also swear I've seen where teams spread themselves thin trying to make an updated UI version concurrently with their main branch only for the updated UI version to fall so far behind on features (or get worked on so rarely) that they abandoned it to fix it later...
"Public funding doesn't get you great coders, it gets you coders who are great at filling out government forms."
Getting paid to deliver a software product that someone wants advances humanity. Getting paid to make your own personal project provides jobs for politician's cousins.
For Blender I agree. I don't feel like gIMP ever hit that moment. Blender appears to be serious competitor to 3DSMax/Maya/Houdini etc. gIMP does not appear to be a serious competitor to Photoshop even after they shipped v3
Yes, because it isn't. What version they pump out has nothing to do with viability. It still lacks much of the feature set and functionally of Photoshop, enough so that it's just not a valid comparison, let alone a valid alternative. Like, I've seen people comparing Krita as the better alternative to GIMP, which isn't even designed to fill the same need. But the fact that those comparisons have even occurred should tell you enough about the state of GIMP.
reply