Stephen Wolfram posted comments about MMA vs FOSS development of computationa mathematics:
https://blog.wolfram.com/2019/04/02/why-wolfram-tech-isnt-open-source-a-dozen-reasons/ My gut feeling, and this is purely my opinion, is that Sage (http://www.sagemath.org/) is beginning to worry Wolfram. William Stein's efforts have shown that many different systems can be set up to communicate and solve a common problem. There are, of course, many issues but I think Stein's "common platform" puts pressure on other systems to communicate better. In the long run I think Sage is an excellent "common ground". Many of the comments in this article are of interest to the Axiom community. The comments that follow are purely my opinion, which is subject to change based on my blood sugar and caffeine levels. Wolfram writes: I came up with 12 reasons why I think that it would not have been possible to create the Wolfram technology stack using a free and open-source model. I would be interested to hear your views in the comments section below the blog. A coherent vision requires centralized design High-level languages need more design than low-level languages You need multidisciplinary teams to unify disparate fields Hard cases and boring stuff need to get done too Crowd-sourced decisions can be bad for you Our developers work for you, not just themselves Unified computation requires unified design Unified representation requires unified design Open source doesn’t bring major tech innovation to market Paid software offers an open quid pro quo It takes steady income to sustain long-term R&D Bad design is expensive My comments follow (W) is Wolfram, (T) is me ==================================================== (W) 1. A coherent vision requires centralized design (W) FOSS (free and open-source software) development can work well when design problems can be distributed to independent teams who self-organize around separate aspects of a bigger challenge. If computation were just about building a big collection of algorithms, then this might be a successful approach. (T) Designs are not usually distributed (design by committee). Most software I'm aware of is the result of a single individual or, at most, a very small group. Christopher Alexander did research in distributed design but was not able to demonstrate his design ideas in practice. (https://en.wikipedia.org/wiki/Christopher_Alexander). Sage is designed by William Stein. Maple was Keith Geddes. Reduce was Tony Hearn. Magnus was Gilbert Baumslag, etc. (T) Axiom is "well-factored" so that collections of algorithms can be a principled method of contribution. (T) FOSS does suffer from the "herding cats" problem. Setting goals for a project can be a problem. (W) But Wolfram’s vision for computation is much more profound—to unify and automate computation across computational fields, application areas, user types, interfaces and deployments. To achieve this requires centralized design of all aspects of technology—how computations fit together, as well as how they work. It requires knowing how computations can leverage other computations and perhaps most importantly, having a long-term vision for future capabilities that they will make possible in subsequent releases. (W) You can get a glimpse of how much is involved by sampling the 300+ hours of livestreamed Wolfram design review meetings. (W) Practical benefits of this include: The very concept of unified computation has been largely led by Wolfram. High backward and forward compatibility as computation extends to new domains. Consistent across different kinds of computation (one syntax, consistent documentation, common data types that work across many functions, etc.). (T) Since MMA uses a single input syntax it is certainly easier for beginners. Axiom's strong typing is a high hurdle for a beginner. On the other hand, the fact that each Domain can choose its representation leads to cleaner and more efficient algorithms. Symbolic rewriting (MMA) is one universal technique but so is Equational reasoning. ========================================================= (W) 2. High-level languages need more design than low-level languages (W) The core team for open-source language design is usually very small and therefore tends to focus on a minimal set of low-level language constructs to support the language’s key concepts. Higher-level concepts are then delegated to the competing developers of libraries, who design independently of each other or the core language team. (T) At IBM the Scratchpad team reworked the language a lot. There was a standing joke about the new-new-new-new parser since the language was changed quite frequently. (W) Wolfram’s vision of a computational language is the opposite of this approach. We believe in a language that focuses on delivering the full set of standardized high-level constructs that allows you to express ideas to the computer more quickly, with less code, in a literate, human-readable way. Only centralized design and centralized control can achieve this in a coherent and consistent way. (T) Symbolic Rewriting techniques are well known (https://www.springer.com/gp/book/9783034897792) and hardly a novel design idea. (W) Practical benefits of this include: One language to learn for all coding domains (computation, data science, interface building, system integration, reporting, process control, etc.)—enabling integrated workflows for which these are converging. Code that is on average seven times shorter than Python, six times shorter than Java, three times shorter than R. Code that is readable by both humans and machines. Minimal dependencies (no collections of competing libraries from different sources with independent and shifting compatibility). (T) It is not clear that MMA differs much from Axiom on these measures. In particular, "Code that is readable by humans" is a weakness of every system. Unless you know the algorithm or the programmers intensions, code is not readable. ======================================================== (W) 3. You need multidisciplinary teams to unify disparate fields (T) I don't know if I agree. I'm doing research on unifying computer algebra and proof theory. I look left, then look right, and don't see the rest of the "multidisciplinary teams" (Does intense multiple personality disorder count? :-) ) (W) Self-assembling development teams tend to rally around a single topic and so tend to come from the same community. As a result, one sees many open-source tools tackle only a single computational domain. You see statistics packages, machine learning libraries, image processing libraries—and the only open-source attempts to unify domains are limited to pulling together collections of these single-domain libraries and adding a veneer of connectivity. Unifying different fields takes more than this. (T) This is the basis for my suspicion that Sage is viewed as a threat. Sage is gaining traction (http://www.sagemath.org/development-map.html). The book "Computational Mathematics with SageMath" is free (http://sagebook.gforge.inria.fr/english.html). It includes a list of authors that is quite impressive. Sage has made major inroads in the INRIA research community. (W) Because Wolfram is large and diverse enough to bring together people from many different fields, it can take on the centralized design challenge of finding the common tasks, workflows and computations of those different fields. Centralized decision making can target new domains and professionally recruit the necessary domain experts, rather than relying on them to identify the opportunity for themselves and volunteer their time to a project that has not yet touched their field. (T) It is a major advantage to be able to hire new PhDs to implement code. However, the notion that there must be "centralized decision making" is not important. You don't need a central authority to "identify the opportunity" in a particular field. Indeed, one of the other sections made the point that people decide on their own to automate their field without a "central decision". (W) Practical benefits of this include: Provides a common language across domains including statistics, optimization, graph theory, machine learning, time series, geometry, modeling and many more. Provides a common language for engineers, data scientists, physicists, financial engineers and many more. Tasks that cross different data and computational domains are no harder than domain-specific tasks. Engaged with emergent fields such as blockchain. (T) Axiom has "engaged with emergent fields", such as designing redundancy codes for storage devices or elliptic curve research. MMA is nothing special in this regard. I doubt that someone trying to solve their problem chooses MMA because it provides a common language to engage with financial engineers. ======================================================== (W) 4. Hard cases and boring stuff need to get done too (T) The "boring stuff" costs me approximately 1 month per year of just low-level maintenance that nobody notices. So it does get done. You just don't see it. (W) Much of the perceived success of open-source development comes from its access to “volunteer developers.” But volunteers tend to be drawn to the fun parts of projects—building new features that they personally want or that they perceive others need. While this often starts off well and can quickly generate proof-of-concept tools, good software has a long tail of less glamorous work that also needs to be done. This includes testing, debugging, writing documentation (both developer and user), relentlessly refining user interfaces and workflows, porting to a multiplicity of platforms and optimizing across them. Even when the work is done, there is a long-term liability in fixing and optimizing code that breaks as dependencies such as the operating system change over many years. (T) Making Axiom work on many platforms (eg linux, mac, windows, android (phones and tablets) takes a LOT of time and effort. (W) While it would not be impossible for a FOSS project to do these things well, the commercially funded approach of having paid employees directed to deliver good end-user experience does, over the long term, a consistently better job on this “final mile” of usability than relying on goodwill. (T) I'm pretty sure that paying me well would be a pleasant surprise. Axiom could certainly use better "final mile" work. But Axiom is a research platform, not an MMA competitor. Funding sources for FOSS research do not exist. Believe me, I've tried. (W) Some practical benefits of this include: Tens of thousands of pages of consistently and highly organized documentation with over 100,000 examples. The most unified notebook interface in the world, unifying exploration, code development, presentation and deployment workflows in a consistent way. Write-once deployment over many platforms both locally and in the cloud. (T) I wish Axiom had the resources to produce more documentation. It is clearly one of the stated goals. ====================================================== (W) 5. Crowd-sourced decisions can be bad for you (W) While bad leadership is always bad, good leadership is typically better than compromises made in committees. (T) I'm clearly a bad leader. I'm the first to acknowledge that. And the "crowd-sourced decisions" that led to the fork was clearly bad for Axiom. But it is much too early to tell what the long term results will be. (In 1972, Chinese premier Zhou Enlai was asked about the impact of the French Revolution. “Too early to say,” he replied). (W) Your choice of computational tool is a serious investment. You will spend a lot of time learning the tool, and much of your future work will be built on top of it, as well as having to pay any license fees. In practice, it is likely to be a long-term decision, so it is important that you have confidence in the technology’s future. (T) I'm not sure that "license fees" is really a FOSS issue. As for "confidence in the technology's future", there is a rather interesting decision to be made. Businesses die (The SBA goes on to state that only 25% make it to 15 years or more. (https://www.investopedia.com/slide-show/top-6-reasons-new-businesses-fail/)). Soft Warehouse is gone (DERIVE), Symbolics is gone (MACSYMA), MapleSoft was sold (MAPLE), NAG removed AXIOM from the market, etc. So what happens when Wolfram Research goes out of business? Do you think MMA will be open-sourced? Do you think anyone is capable of maintaining it as FOSS? Businesses fail. Even IBM? (https://www.forbes.com/sites/steveandriole/2018/03/13/ibms-way-out-sell-itself/#789632285874) (W) Because open-source projects are directed by their contributors, there is a risk of hijacking by interest groups whose view of the future is not aligned with yours. The theoretical safety net of access to source code can compound the problem by producing multiple forks of projects, so that it becomes harder to share your work as communities are divided between competing versions. (T) Axiom forked. The forked project has its own "view of the future" which is not "aligned with Axiom". That hardly matters, since we are not in competition. Axiom is a research project, currently focused on proving algorithms. I don't expect to see MMA efforts at proving their algorithms correct. In fact, I'm not sure how you would prove algorithms based on rewrite sematics correct. (W) While the commercial model does not guarantee protection from this issue, it does guarantee a single authoritative version of technology and it does motivate management to be led by decisions that benefit the majority of its users over the needs of specialist interests. (T) "specialist interests" would be another term for "your problem". (W) In practice, if you look at Wolfram Research’s history, you will see: Ongoing development effort across all aspects of the Wolfram technology stack. Consistency of design and compatibility of code and documents over 30 years. Consistency of prices and commercial policy over 30 years. =========================================================== (W) 6. Our developers work for you, not just themselves (W) Many open-source tools are available as a side effect of their developers’ needs or interests. Tools are often created to solve a developer’s problem and are then made available to others, or researchers apply for grants to explore their own area of research and code is made available as part of academic publication. Figuring out how other people want to use tools and creating workflows that are broadly useful is one of those long-tail development problems that open source typically leaves to the user to solve. (W) Commercial funding models reverse this motivation. Unless we consider the widest range of workflows, spend time supporting them and ensure that algorithms solve the widest range of inputs, not just the original motivating ones, people like you will not pay for the software. Only by listening to both the developers’ expert input and the commercial teams’ understanding of their customers’ needs and feedback is it possible to design and implement tools that are useful to the widest range of users and create a product that is most likely to sell well. We don’t always get it right, but we are always trying to make the tool that we think will benefit the most people, and is therefore the most likely to help you. (W) Practical benefits include: Functionality that accepts the broadest range of inputs. Incremental maintenance and development after initial release. Accessible from other languages and technologies and through hundreds of protocols and data formats. (T) MMA clearly wins on this one. But their motivation is "to create a project that is most likely to sell well". Axiom's goal is to create a project that is proven correct. That won't make it sell well, or even increase its adoption. But Axiom is computational mathematics and well-founded mathematics ought to be proven correct. What is the point of getting an answer if it is wrong? ========================================================= (W) 7. Unified computation requires unified design (W) Complete integration of computation over a broad set of algorithms creates significantly more design than simply implementing a collection of independent algorithms. (W) Design coherence is important for enabling different computations to work together without making the end user responsible for converting data types, mapping functional interfaces or rethinking concepts by having to write potentially complex bridging code. Only design that transcends a specific computational field and the details of computational mechanics makes accessible the power of the computations for new applications. (W) The typical unmanaged, single-domain, open-source contributors will not easily bring this kind of unification, however knowledgeable they are within their domain. (W) Practical benefits of this include: Avoids costs of switching between systems and specifications (having to write excessive glue code to join different libraries with different designs). Immediate access to unanticipated functions without stopping to hunt for libraries. Wolfram developers can get the same benefits of unification as they create more sophisticated implementations of new functionality by building on existing capabilities. The Wolfram Language’s task-oriented design allows your code to benefit from new algorithms without having to rewrite it. (T) Actually, I think Axiom dominates MMA in this instance. Axiom's Category / Domain / Package architecture is much better than MMA's one-sink-holds-all design. ========================================================= (W) 8. Unified representation requires unified design (W) Computation isn’t the only thing that Wolfram is trying to unify. To create productive tools, it is necessary to unify the representation of disparate elements involved in a computational workflow: many types of rich data, documents, interactivity, visualizations, programs, deployments and more. A truly unified computational representation enables abstraction above each of these individual elements, enabling new levels of conceptualization of solutions as well as implementing more traditional approaches. (W) The open-source model of bringing separately conceived, independently implemented projects together is the antithesis of this approach—either because developers design representations around a specific application that are not rich enough to be applied in other applications, or if they are widely applicable, they only tackle a narrow slice of the workflow. (W) Often the consequence is that data interchange is done in the lowest common format, such as numerical or textual arrays—often the native types of the underlying language. Associated knowledge is discarded; for example, that the data represents a graph, or that the values are in specific units, or that text labels represent geographic locations, etc. The management of that discarded knowledge, the coercion between types and the preparation for computation must be repeatedly managed by the user each time they apply a different kind of computation or bring a new open-source tool into their toolset. (W) Practical examples of this include: The Wolfram Language can use the same operations to create or transform many types of data, documents, interfaces and even itself. Wolfram machine learning tools automatically accept text, sounds, images and numeric and categorical data. As well as doing geometry calculations, the geometric representations in the Wolfram Language can be used to constrain optimizations, define regions of integration, control the envelope of visualizations, set the boundary values for PDE solvers, create Unity game objects and generate 3D prints. (T) So where is the design documentation for this "Unified Representation"? Is the claim that any and all other representations (e.g. the quoted text, sounds, images, etc) are just instances of this "Unified Representation"? Or is it the case that to handle data (e.g. Lidar data) you might have to write code to handle it? How is that different from what Python does (such as in SageMath)? Can MMA send me an image without resorting to "native data types"? For some reason this seems like a vacuous claim. Or maybe I'm not clever enough, always a possibility ======================================================= (W) 9. Open source doesn’t bring major tech innovation to market (T) Really? What about ROS (http://www.ros.org/) for robots and self-driving cars. Or Tex for documentation. Or. the Pinger project, which did network monitoring of data centers using SNMP, etc. (W) FOSS development tends to react to immediate user needs—specific functionality, existing workflows or emulation of existing closed-source software. Major innovations require anticipating needs that users do not know they have and addressing them with solutions that are not constrained by an individual’s experience. (W) As well as having a vision beyond incremental improvements and narrowly focused goals, innovation requires persistence to repeatedly invent, refine and fail until successful new ideas emerge and are developed to mass usefulness. Open source does not generally support this persistence over enough different contributors to achieve big, market-ready innovation. This is why most large open-source projects are commercial projects, started as commercial projects or follow and sometimes replicate successful commercial projects. (T) Axiom is working to prove computational mathematics software. That seems to be "a vision beyond incremental improvements". (W) While the commercial model certainly does not guarantee innovation, steady revenue streams are required to fund the long-term effort needed to bring innovation all the way to product worthiness. Wolfram has produced key innovations over 30 years, not least having led the concept of computation as a single unified field. (W) Open source often does create ecosystems that encourage many small-scale innovations, but while bolder innovations do widely exist at the early experimental stages, they often fail to be refined to the point of usefulness in large-scale adoption. And open-source projects have been very innovative at finding new business models to replace the traditional, paid-product model. (W) Other examples of Wolfram innovation include: Wolfram invented the computational notebook, which has been partially mirrored by Jupyter and others. Wolfram invented the concept of automated creation of interactive components in notebooks with its Manipulate function (also now emulated by others). Wolfram develops automatic algorithm selection for all task-oriented superfunctions (Predict, Classify, NDSolve, Integrate, NMinimize, etc.). (T) Actually, the "computational notebook" idea existed long before "Wolfram invented the computational notebook". Magnus had this idea (along with the "zero-learning curve interface" which nobody else has) and an implementation long before Wolfram. Mike Dewar used computer algebra to select numerical algorithms in 1991 (Dewar, Michael "Interfacing Algebraic and Numeric Computation", PhD Thesis, University of Bath (1991)) also: (https://dl.acm.org/citation.cfm?doid=143242.143252) =========================================================== (W) 10. Paid software offers an open quid pro quo (W) Free software isn’t without cost. It may not cost you cash upfront, but there are other ways it either monetizes you or that it may cost you more later. The alternative business models that accompany open source and the deferred and hidden costs may be suitable for you, but it is important to understand them and their effects. If you don’t think about the costs or believe there is no cost, you will likely be caught out later. (W) While you may not ideally want to pay in cash, I believe that for computation software, it is the most transparent quid pro quo. (T) Not everyone shares the belief. (W) “Open source” is often simply a business model that broadly falls into four groups: (W) Freemium: The freemium model of free core technology with additional paid features (extra libraries and toolboxes, CPU time, deployment, etc.) often relies on your failure to predict your longer-term needs. Because of the investment of your time in the free component, you are “in too deep” when you need to start paying. The problem with this model is that it creates a motivation for the developer toward designs that appear useful but withhold important components, particularly features that matter in later development or in production, such as security features. (T) I'm unaware of any FOSS computation mathematics that uses this model. On the other hand, MMA is sold at a discount to students to achieve "lock-in" because you 're "in too deep" with code you already wrote. (W) Commercial traps: The commercial trap sets out to make you believe that you are getting something for free when you are not. In a sense, the Freemium model sometimes does this by not being upfront about the parts that you will end up needing and having to pay for. But there are other, more direct traps, such as free software that uses patented technology. You get the software for free, but once you are using it they come after you for patent fees. Another common trap is free software that becomes non-free, such as recent moves with Java, or that starts including non-free components that gradually drive a wedge of non-free dependency until the supplier can demand what they want from you. (T) Java is becoming "non-free" due to commercial interests (Oracle). That doesn't seem to be a FOSS issue at all. (W) User exploitation: Various forms of business models center on extracting value from you and your interactions. The most common are serving you ads, harvesting data from you or giving you biased recommendations. The model creates a motivation to design workflows to maximize the hidden benefit, such as ways to get you to see more ads, to reveal more of your data or to sell influence over you. While not necessarily harmful, it is worth trying to understand how you are providing hidden value and whether you find that acceptable. (T) Lets see... who started the major push for ad-based business. It certainly wasn't a FOSS effort. In fact, FOSS has worked to limit ads (e.g. Adblock on Firefox). (W) Free by side effect: Software is created by someone for their own needs, which they have no interest in commercializing or protecting. While this is genuinely free software, the principal motivation of the developer is their own needs, not yours. If your needs are not aligned, this may produce problems in support or development directions. Software developed by research grants has a similar problem. Grants drive developers to prioritize impressing funding bodies who provide grants more than impressing the end users of the software. With most research grants being for fixed periods, they also drive a focus on initial delivery rather than long-term support. In the long run, misaligned interests cost you in the time and effort it takes you to adapt the tool to your needs or to work around its developers’ decisions. Of course, if your software is funded by grants or by the work of publicly funded academics and employees, then you are also paying through your taxes—but I guess there is no avoiding that! (T) I need MMA to prove the algorithms correct. Clearly this will be done by simply sending an Email to Wolfram Research. I expect a working result any day now. On the side of reality though, you should read the paper "The Misfortunes of a Trio of Mathematicans Using Computer Algebra Systems. Can we Trust in Them?" (http://www.ams.org/notices/201410/rnoti-p1249.pdf). To be fair, I spoke with an MMA developer this summer. The problem was more complex than it would appear and it has since been fixed. That said, the "lessons learned" still apply. (T) Also, quoting Franklin Chen (C) from https://conscientiousprogrammer.com/blog/2014/11/06/when-a-computer-algebra-program-gives-wrong-answers/ (C) They reported the Mathematica bug to Wolfram Research but got no useful reply, and at the next release of Mathematica, the bug was still not fixed. (C) There were other bugs they found as well. (C) Wolfram Research never gave any feedback, and does not publish a list of known bugs. (C) Lessons to learn (C) When there is a bug in proprietary, closed-source software, you are completely helpless. The bug may not even be acknowledged, much less fixed, and you could not fix it yourself even if you wanted to. (C) There is value in having an alternative tool: without independent work using Maple, the bugs in Mathematica may never have been discovered. Diversity is good. (C) All scientists should be aware that the tools they use can be buggy, and therefore computational results can only be trusted as much as the specific versions of software they use can be trusted. (W) In contrast, the long-term commercial model that Wolfram chooses motivates maximizing the usefulness of the development to the end users, who are directly providing the funding, to ensure that they continue to choose to fund development through upgrades or maintenance. The model is very direct and upfront. We try to persuade you to buy the software by making what we think you want, and you pay to use it. The users who make more use of it generally are the ones who pay more. No one likes paying money, but it is clear what the deal is and it aligns our interest with yours. (W) Now, it is clearly true that many commercial companies producing paid software have behaved very badly and have been the very source of the “vendor lock-in” fear that makes open source appealing. Sometimes that stems from misalignment of management’s short-term interest to their company’s long-term interests, sometimes just because they think it is a good idea. All I can do is point to Wolfram history, and in 30 years we have kept prices and licensing models remarkably stable (though every year you get more for your money) and have always avoided undocumented, encrypted and non-exportable data and document formats and other nasty lock-in tricks. We have always tried to be indispensable rather than “locked in.” (W) In all cases, code is free only when the author doesn’t care, because they are making their money somewhere else. Whatever the commercial and strategic model is, it is important that the interests of those you rely on are aligned with yours. (T) "...code is free only when the author doesn't care"??? I've spent the last 19 years of my life "not caring"? How damn clueless of me. (W) Some benefits of our choice of model have included: An all-in-one technology stack that has everything you need for a given task. No hidden data gathering and sale or external advertising. Long-term development and support. ====================================================== (W) 11. It takes steady income to sustain long-term R&D (T) Yes, it does. According to my records, I've spent about $3,000 per year "supporting Axiom" (nearly $60,000 so far). But that doesn't mean that the steady income has to come from "sales". It comes from having a job. Research is something you do because "you have to do it". It would be nice to have a steady stream of income to do research full time but it is not a requirement for doing research. Ask any PhD student. (W) Before investing work into a platform, it is important to know that one is backing the right technology not just for today but into the future. You want your platform to incrementally improve and to keep up with changes in operating systems, hardware and other technologies. This takes sustained and steady effort and that requires sustained and steady funding. (T) Yes, it does. Is that a surprise? (W) Many open-source projects with their casual contributors and sporadic grant funding cannot predict their capacity for future investment and so tend to focus on short-term projects. Such short bursts of activity are not sufficient to bring large, complex or innovative projects to release quality. (T) Well, this non-sequitur is poorly reasoned. (W) While early enthusiasm for an open-source project often provides sufficient initial effort, sustaining the increased maintenance demand of a growing code base becomes increasingly problematic. As projects grow in size, the effort required to join a project increases. It is important to be able to motivate developers through the low-productivity early months, which, frankly, are not much fun. Salaries are a good motivation. When producing good output is no longer personally rewarding, open-source projects that rely on volunteers tend to stall. (T) True. Most open source projects die when the lead developer stops working on it. But most closed source projects die when the company dies. (W) A successful commercial model can provide the sustained and steady funding needed to make sure that the right platform today is still the right platform tomorrow. (T) Until the company disappears. What becomes of Mathematica when Wolfram Research closes? (W) You can see the practical benefit of steady, customer-funded investment in Wolfram technology: Regular feature or maintenance upgrades for over 30 years. Cross-platform support maintained throughout our history. Multi-year development projects as well as short-term projects. ==================================================== (W) 12. Bad design is expensive (T) It is extremely expensive to "trust wrong answers", especially when you have no way to understand the algorithms used due to their closed source nature. One bad result could ruin your product or your PhD. (W) Much has been written about how total cost of ownership of major commercial software is often lower than free open-source software, when you take into account productivity, support costs, training costs, etc. While I don’t have the space here to argue that out in full, I will point out that nowhere are those arguments more true than in unified computation. Poor design and poor integration in computation result in an explosion of complexity, which brings with it a heavy price for usability, productivity and sustainability. (W) Every time a computation chokes on input that is an unacceptable type or out of acceptable range or presented in the wrong conceptualization, that is a problem for you to solve; every time functionality is confusing to use because the design was a bit muddled and the documentation was poor, you spend more of your valuable life staring at the screen. Generally speaking, the users of technical software are more expensive people who are trying to produce more valuable outputs, so wasted time in computation comes at a particularly high cost. (T) Is the implication that MMA never "chokes on input" or "presents a wrong conceptualization"? Or is the implication that FOSS makes it "a problem for you to solve" but commercial software will make it their problem? (W) It’s incredibly tough to keep the Wolfram Language easy to use and have functions “just work” as its capabilities continue to grow so rapidly. But Wolfram’s focus on global design (see it in action) together with high effort on the final polish of good documentation and good user interface support has made it easier and more productive than many much smaller systems. ================================================== (W) Summary: Not being open source makes the Wolfram Language possible (W) As I said at the start, the open-source model can work very well in smaller, self-contained subsets of computation where small teams can focus on local design issues. Indeed, the Wolfram Technology stack makes use of and contributes to a number of excellent open-source libraries for specialized tasks, such as MXNet (neural network training), GMP (high-precision numeric computation), LAPACK (numeric linear algebra) and for many of the 185 import/export formats automated behind the Wolfram Language commands Import and Export. Where it makes sense, we make self-contained projects open source, such as the Wolfram Demonstrations Project, the new Wolfram Function Repository and components such as the Client Library for Python. (W) But our vision is a grand one—unify all of computation into a single coherent language, and for that, the FOSS development model is not well suited. (W) The central question is, How do you organize such a huge project and how do you fund it so that you can sustain the effort required to design and implement it coherently? Licenses and prices are details that follow from that. By creating a company that can coordinate the teams tightly and by generating a steady income by selling tools that customers want and are happy to pay for, we have been able to make significant progress on this challenge, in a way that is designed ready for the next round of development. I don’t believe it would have been possible using an open-source approach and I don’t believe that the future we have planned will be either. (W) This does not rule out exposing more of our code for inspection. However, right now, large amounts of code are visible (though not conveniently or in a publicized way) but few people seem to care. It is hard to know if the resources needed to improve code access, for the few who would make use of it, are worth the cost to everyone else. (W) Perhaps I have missed some reasons, or you disagree with some of my rationale. Leave a comment below and I will try and respond. (T) It seems to me that RedHat managed to make a profit and sustain a company based on FOSS. (T) Computational mathematics needs to be publicly available. Or do we have a modern day Tartaglia? (http://www.ms.uky.edu/~corso/teaching/math330/Cardano.pdf) (T) "“Yeah, well, you know, that's just, like, your opinion, man.”" -- Jeff Lebowski (Jeff Bridges in The Big Lebowski) MMA is an amazing piece of software. I'm not sure it needs to contrast itself with FOSS. This is all my opinion and hardly worth the read. If you got this far I apologize for taking up your time. Tim _______________________________________________ Axiom-developer mailing list Axiom-developer@nongnu.org https://lists.nongnu.org/mailman/listinfo/axiom-developer