>Most of these are about wanting control over the design of the software - but releasing their code doesn't have any impact on that - I don't get it? [...] how releasing your source lead to bad design?
The way to interpret his argument is to imagine an alternate past history where Mathematica was open source from the beginning and how that would have lead to an inferior product. He wrote:
>[...] I think that it would not have been possible to create the Wolfram technology stack using a free and open-source model.
So instead of thinking they can just go ahead and open source what they have today and everything would be just fine, we need to consider how game theory would have played out in an alternate universe where they tried FOSS model from the beginning.
Maybe his argument is still flawed but to at least entertain his scenario, let's study other projects and compare:
- open source GIMP is considered very good -- but also is several years behind closed-source Adobe Photoshop in features
- OpenCAD, OpenSCAD not as full-featured as proprietary Autodesk, SolidWorks, etc
- LibreOffice has less features the MS Office
- Code::Blocks and Eclipse as IDE for C++ coding not as good as MS Visual Studio
- OpenStack less features than AWS
- SageMath has less symbolic computing features than Wolfram Mathematica
To counterbalance the above, we can try to identify open source projects that are equal or superior to proprietary solutions:
- LibOpus is superior algorithm to Fraunhofer FDK AAC
- Linux (server) is comparable or superior to MS Windows (Server).
- GCC, Clang comparable to Microsoft "cl.exe" compiler.
Is there a pattern to the above? It seems like a combination of :
- big complex software with lots of features
- GUI
... often means that open-source collaboration model falls behind the proprietary commercial offerings. Why?
So if Wolfram tried to open-source Mathematica from the beginning of its history, a different proprietary XYZ software may have outcompeted them. E.g. the salaried programmers working on today's Mathematica wouldn't have worked on the open-source Mathematica for free because they would have been at XYZ Corporation. In that alternate timeline, we'd complain today that "Mathematica isn't as good as XYZ"
> Is there a pattern to the above? It seems like a combination of [a] big complex software with lots of features, [and a] GUI... often means that open-source collaboration model falls behind the proprietary commercial offerings. Why?
Interaction Design (IxD) isn’t something that can be done piecemeal; it needs to be done top-down, with an overarching vision, to achieve its ends (an intuitive design.) Intuition comes from obvious implicit structure, where you can easily “get into the mind of” the designer, discover their mental model, and then use it to predict how other features will work. If there’s no single designer (or very-tightly-constraining design document) then there’s no unified mental model to learn, and so no intuition.
And there are relatively-few professional designers in the open-source community.
It’s easy and low-friction for a professional programmer to “scratch their own itch” by implementing just one little change in a piece of software, and by that means, FOSS software’s source code quality can be improved piecemeal. But it’s both difficult (you have to re-do everything at once for it to help) and high-friction (hard to convince the software maintainers to accept the change) to contribute a design change to FOSS software. So useful FOSS software design changes are almost impractical (unless the stars align); and so professional designers just don’t bother to even try to take part in the community.
So instead, FOSS software just tends to languish without any unified design vision ever being applied to it. (Or with a bad, arbitrary, and unintuitive design vision being contributed at some point by some inexperienced designer, and being accepted because the maintainers are all programmers with no sense for IxD themselves.)
There’s also the fact that a lot of IxD needs to be informed by data — e.g. user workflow studies — that cost money to run; and FOSS projects don’t tend to have the budget for this, or don’t tend to see it as a priority for spending what budget they do have, since they have no “design advocate” on the team to ask for it.
I think you're skipping the really big obvious answer, which isn't features or graphical interfaces: Money. Photoshop, Autodesk, Office, etc. are huge money makers, so they can throw developers and designers at improving things. Server Linux is largely driven by billion-dollar companies investing.
I believe GUI is a huge part of it. My rationale is that sweating the details of the GUI actually requires a profound amount of work, that is not at the top of the list of things that programmers enjoy working on. The the only way to get it done is to hire an army of well paid programmers to do it. And things like office and graphics software are nothing without GUI.
Second, some software builds on a body of proprietary domain knowledge that someone happens to own. I'd put mechanical CAD in that category. Probably the symbolic computing technology of Mathematica as well. In some cases, users of specialized engineering software actually put up with horrifying user interfaces because the software vendor has a lock on the domain knowledge.
The successes of open source include anything without a user interface, such as the infrastructure of the universe, and non domain specific programming tools.
Agreed that GUI is a huge part of it, but I'd say for a different reason. There are almost no UI/UX designers contributing to open source projects. At the very least the ratio of them to programmers is incredibly low, far lower than at any company whose main product depends heavily on its GUI like office or graphics software.
OSS GUIs are exactly what you get if you leave it completely up to an army of pure programmers (whether well-paid or not).
And in this alternate past history, how would they have generated an income? I think your clarification is spot-on, and the debate around whether they could or would have been out-competed is an interesting one, but fundamentally they need to be able to generate revenue somehow.
I totally get open-source for libraries/components/building blocks/etc, and strategies like “commoditise your complements” have been mentioned elsewhere. But I’m struggling to see how open-sourcing the actual end-user product isn’t just literally giving away everything for free?
Did any of these open-source projects that lag behind had a budget that at least was of the same order of magnitude of their proprietary counterparts? I don't think so.
OBS is another counterexample that is heavy on GUI and absolutely superior to similar solutions (where they don't just fork it and hide it).
Proprietary and open-source modes share the same challenges. 1. Developers need incentives and it has to be sustainable. Money is the biggest of them but reputation, fun and self-realization also matters. 2. Organization and scale. A team of experts supported by staff can do a lot more than a single developer. But a large corporation is inefficient and can fail to deliver. 3. Momentum. It's difficult for a software to compete with large established softwares like AutoDesk, MS Office and Photoshop even if delivers the same features and performance.
>Did any of these open-source projects that lag behind had a budget that at least was of the same order of magnitude of their proprietary counterparts? I don't think so.
No they didn't and that's why I put those lagging open-source projects as examples to make readers imagine that an alternate-history-open-source Mathematica may have lagged behind like them too.
I think you lost track of the argument put forth by this thread's essay from Jon McLoone of Wolfram. Your emphasis about "no big budget" actually supports his listed benefits of the paid model in: https://blog.wolfram.com/2019/04/02/why-wolfram-tech-isnt-op...
Again, when he wrote : >[...] I think that it would not have been possible to create the Wolfram technology stack using a free and open-source model.
... he's saying you wouldn't have the comprehensive Mathematica product we see today with the open source model. Perhaps the histories of how GIMP/OpenCAD/SageMath evolved supports his point that Mathematica was correct in not choosing their open-source model?
More or extended features are not automatically a good thing for the users. Microsoft extended Kerberos with incompatible changes, re-published it under a diffeerent name, users lost open source benefits and became locked in to the Microsoft version, and the original developers were not provided with the changes. Microsoft did almost the same thing with Sun's Java when Microsoft made its incompatible version, despite Java being available in a free as in freedom version and at no cost.
The four essential freedoms[1] might not make you rich, but they will keep providing you with true freedom.
Wolfram Mathematica would be a more valuable contribution to the future of humankind, if the essential freedoms were guaranteed.
[1] gnu.org The Free Software Definition: The four essential freedoms.
true, why is blender special? it was originally a closed source program with a small community that became open source later, but it’s evolved massively since then and become much more polished and easier to use, which virtually no open source project can say
KiCAD is another package that I think is fairly competitive at this point. It’s not going to kill Altium, but it’s improved greatly in the last 3 years.
I actually disagree and think Altium will, in fact, be Victim #001 of KiCad. The question becomes: "Is Altium <n> thousand dollars better than KiCad?" And a lot of the time the answer will now be "No."
I already split my designs about 50/50 between Altium and KiCad--and that's before KiCad 6.0 which is imminent (6.0RC2 exists right now).
1) KiCad has one killer feature: it's cross platform.
I would argue that this will, over time, kill anything that isn't. Mostly because "open a VM in the cloud and do all your work there" is becoming really common.
2) PCB software, by and large, doesn't need new features. PCB software does need features that work.
Altium is infuriating with not killing bugs and introducing new ones every release.
3) Altium and bunch are basically blocking access to libraries without a subscription fee. That's going to erase Altium for use by small people. This drives me up a tree because it prevents me from sharing a design.
KiCad will slowly but surely eat everything at the bottom and then start upwards--there's just simply no other decent alternative in the space.
Not having linux support is a big self-own for Altium. Its main high-end competitor, Cadence OrCAD/Allegro, has top-tier Linux support. Altium tried to do a "365" thing like Microsoft, and I doubt that's really what Altium users want.
Altium was about to be a good high-end piece of software until they did this. Now it's homeless and it will lose to KiCAD for low-end things and Cadence for high-end.
To me, the self-own was trying to lock libraries behind subscription.
Altium had just gotten to the point that everybody providing chips was also providing an Altium library footprint and symbol.
It was really nice--for about 12-18 months.
And then I started getting Altium libraries that I couldn't pull the symbol out of and couldn't use without being logged in.
Fscking idiots. Talk about snatching defeat from the jaws of victory.
They had finally reached the point that they were an alternative to Orcad in commercial engagements, and then they gave it away in order to try to go after subscription revenue.
I literally picked up KiCad the day after I couldn't extract a symbol from an Altium library and add a couple of missing pins for a new part. I was that infuriated.
Right now, I'm evaluating KiCad 6.0 for work. I'll probably transfer over completely for personal projects (I've been doing more and more personal projects in KiCad over time with only PCB->Schematic back annotation holding me back from full transfer--that's fixed in 6.0 with the new file formats). It may take a bit, but I'll probably transfer over to KiCad for work projects that I'm the only designer on once I get a couple of projects under my belt with KiCad 6.0.
There is no design that I’ll ever do that KiCAD can’t handle. I get the sense that most of the commercial complex PCB (motherboards, phones, etc) are likely to stay Altium for a good long while. Is that not the case?
Those designs probably aren't in Altium. They're probably in something like Mentor Xpedition or Cadence Allegro.
This is why I suggest that Altium is likely to be the first victim.
The non-Altium proprietary systems have a lot of legacy to hold them in place (like parts database integration across your company). In addition, they do have some very advanced features around routing matched memory buses and the like.
If, however, your design doesn't need that, KiCad will cover you, and Altium won't bring anything you need to the table.
KiCad's library management isn't powerful enough for (most) commercial work. It has a good foundation but there is too much critical functionality that is not implemented yet.
I'm not sure if/how this is improved in KiCad 6 but from the KiCad 5 tutorials I've seen, "manually match symbols to footprints" was its approach to library management :/
I'm learning PCB design with https://github.com/horizon-eda/horizon instead — and here library (pool) management comes first. You actually place full "parts" (that associate symbols and footprints and other metadata) onto schematics — and if you don't want to decide on a particular model number, you can still place a "base" part (e.g. "generic 5k resistor") and change it later. Oh, and the schematic editor actually edits nets, rather than what KiCad does (seemingly just a basic CAD drawing that gets analyzed into a netlist as a very separate explicit step).
1) I see its value. The cacophony needs to be tamed. And a larger company can dedicate staff to keeping the library up-to-date and organized.
But it's kind of like the problems between a monorepo and multiple repositories.
I've never been part of a company where we could afford to dedicate people to BOM management and library control. I know a really good person who does this--but the companies she works at move at a sclerotic pace. They're medical or aerospace. They have zillions of ISO certifications and testing requirements. You have to file 3 forms to put a new part in the "system". And this is fine--I want someone like her preventing random changes sneaking into a medical device, thanks.
And even still, she has to fight with people every day to hold back the chaos.
2) Everybody has a different notion of "library management" and someone else's version will always be an impediment.
"Library management" is, practically by definition, opinionated. Mine is too.
I have a very idiosyncratic way of parts numbering my resistors, capacitors, inductors and a few other things in the system. It's optimized for the fact that if you put things in boxes in order sorted by those numbers, I can browse through our inventory very quickly and pull parts, values, and footprints that I need as well as know if I don't have something or have a substitute. All without having to consult some master spreadsheet or database that will always be out of date.
It drives the aforementioned library organizer crazy. She wants me to use the "standard" parts numbers and classifications. However, she also acknowledges that I have a solid reason for what I chose. If I ever manage to hire her, I will let her at it and I will comply with what she wants.
> "manually match symbols to footprints" was its approach to library management :/
It is, but I also find that "footprint management" at the schematic simply isn't as useful as people make it out to be. "Generic" footprints are fine when you're throwing around DIP chips or 1206 components. However, footprints get a lot less "generic" and interchangeable when you're working with 0402 and smaller components.
A lot of my components wind up with "unique" footprints anyway.
The way to interpret his argument is to imagine an alternate past history where Mathematica was open source from the beginning and how that would have lead to an inferior product. He wrote:
>[...] I think that it would not have been possible to create the Wolfram technology stack using a free and open-source model.
So instead of thinking they can just go ahead and open source what they have today and everything would be just fine, we need to consider how game theory would have played out in an alternate universe where they tried FOSS model from the beginning.
Maybe his argument is still flawed but to at least entertain his scenario, let's study other projects and compare:
- open source GIMP is considered very good -- but also is several years behind closed-source Adobe Photoshop in features
- OpenCAD, OpenSCAD not as full-featured as proprietary Autodesk, SolidWorks, etc
- LibreOffice has less features the MS Office
- Code::Blocks and Eclipse as IDE for C++ coding not as good as MS Visual Studio
- OpenStack less features than AWS
- SageMath has less symbolic computing features than Wolfram Mathematica
To counterbalance the above, we can try to identify open source projects that are equal or superior to proprietary solutions:
- LibOpus is superior algorithm to Fraunhofer FDK AAC
- Linux (server) is comparable or superior to MS Windows (Server).
- GCC, Clang comparable to Microsoft "cl.exe" compiler.
Is there a pattern to the above? It seems like a combination of :
- big complex software with lots of features
- GUI
... often means that open-source collaboration model falls behind the proprietary commercial offerings. Why?
So if Wolfram tried to open-source Mathematica from the beginning of its history, a different proprietary XYZ software may have outcompeted them. E.g. the salaried programmers working on today's Mathematica wouldn't have worked on the open-source Mathematica for free because they would have been at XYZ Corporation. In that alternate timeline, we'd complain today that "Mathematica isn't as good as XYZ"