Is there a reason to not take an open source approach and collaborate on projects?
I’ll answer even though the question wasn’t addressed to me. As the author of Giac.jl and OpenSymbolicRules (still WIP), I’m one of the people it is implicitly about.
I remember a very short private discussion we had at JuliaCon 2026 in Mainz, where you told me:
We don’t want to compete against M*
(* put your favorite proprietary CAS name here)
I also think you should admit that the positioning of Symbolics.jl in the general-CAS area is unclear. Your own tracker shows it. In August, a user asked on #59 whether parity with SymPy was still being pursued, and you answered:
The main focus of Symbolics is definitely very different from sympy, but we should continue to try and superset sympy anyways.
(question · your reply)
I took you at your word, so here is my answer to your question, with links.
You write:
I can just claude this all to be pulled from these repos, but it seems silly to be wasting tokens like this. Let’s just collaborate? … I hope to see a first pull request somewhere.
Chris, the first pull requests already exist. They are in your repos, and some of them have been there for most of a year:
- JuliaSymbolics/Symbolics.jl#1843:
factor,sqrfree,discriminant,resultant, the bread and butter of a general CAS. Opened April 21, 2026. As of today: 202 days, zero comments, zero reviews. - JuliaSymbolics/Symbolics.jl#1844: preserve exact
πin periodic transcendental solve. Opened April 21, 2026. Still open after about 7 months. - JuliaSymbolics/Symbolics.jl#1983 and #1984: mathematical assumptions and variable domains. Opened September 13, 2026. The only review #1984 ever received came 13 days in, from an automated AI agent running under your account, and it begins with not written or reviewed by Chris.
- JuliaSymbolics/SymbolicIntegration.jl#136, #138, #140, #141: exact algebraic numbers in Risch antiderivatives, removal of deprecated calls, correct sign decisions on non-real algebraic numbers, exact roots from the rule-based backend. All opened September 13, 2026. All still open.
To be fair, my small soundness fixes (SymbolicUtils.jl#1077, #1081) were merged within days. What stays unreviewed is the substantive general-CAS work, the work that would make Symbolics.jl more than an expression layer for a numerical stack.
So when an AI agent running under a maintainer’s account reviews my PRs faster than any human does, and the proposal on the table is I can just claude this all to be pulled from these repos, I don’t read that as an offer to collaborate. PRs go in, tokens come out, and no human is involved. I would call that an ingestion pipeline with a queue problem.
You also ask:
Why two rule systems? I mean, we can put agents to copy each other’s rules or… we can just have a repo of rules parsed differently?
That repo exists. It is called OpenSymbolicRules. It is a language-neutral JSON format with a validated JSON Schema, carrying RUBI’s integration rules, designed so that any CAS (Julia, Python/SymPy, Java/SymJa, Rust, JavaScript) can consume them with a standard JSON parser. A rule is only worth something once it is proved, so the project goes further than a pile of JSON: 101 rules across trigonometry, algebra, logic and calculus are authored in Lean 4 and proved against Mathlib. Every proof is replayed in the Lean kernel, the soundness of the reference rewriter itself is proved (OSR.normalize_sound), and the verification reports are published so that anyone can rebuild them from source without trusting the publisher. One of my early calculus rules did not survive that treatment. Lean refuted it with a counterexample, and catching that kind of error is the reason the project exists. A "certified": true field should mean a kernel-checked proof and nothing less. I invite you to contribute there. Mathematical rules can live outside any single language, in a neutral format consumed by different clients.
One thing your side did recently deserves credit: SciMLBenchmarks.jl#1887, which compares Symbolics.jl, SymEngine.jl and SymPy side by side on identical workloads, and was merged within two days of you asking for SymPy to be added. The instinct is right, so please follow it through and look at which engine is missing from the table: Giac.jl. The announcement that opened this thread names it: Performance exceeds SymPy.jl, but not Giac.jl, and SymJ.jl is beaten by Giac.jl in many areas. The benchmark includes SymEngine.jl, which is one C++ wrapper, and leaves out the C++ wrapper that outperforms the rest on speed. The workloads chosen are also symbolic-numerics ones (expansion, substitution, codegen, CSE), the axis where SciML wins by design. A general CAS is also judged on coverage: how many integrals, limits and equations it actually gets right, on suites nobody in the chart can cherry-pick. The 1680-integral suite compiled by SymbolicIntegration.jl and the 72k+ RUBI problems are available to anyone honest enough to run them, and John’s four packages ship with badges linking to comparative reports against Giac and SymPy. A CAS benchmark that leaves out the strongest open-source baselines (Giac, Maxima) and the proprietary systems measures a selection of opponents and tells us little about the field. Leaving M* off the chart while repeating that you don’t want to compete against M* is the same fuzzy positioning I mentioned above. If you truly do not compete with it, publishing its numbers costs you nothing, and the community finally gets an honest picture of where the Julia ecosystem stands against the systems people actually use for computer algebra.
About not wanting to compete against M*: on general-purpose computer algebra you are not even competing with Giac or SymPy, and the tracker shows it. Assumptions (#98), the defining feature of a general CAS, has been open since March 2021. So have wrong results from simplify (#1725), integer overflow in simplify (#1290), sqrt simplification (#958) and common-factor extraction (#686), some of them for four years. As I argued in Why open-source timelines/roadmaps don’t work, what matters is knowing which problems have been identified and what is preventing progress. On general CAS features, Symbolics.jl documents none of this: no roadmap, no design space, not even an explicit refusal.
Devrait être réduit
The thread moved while I was writing this, so let me respond to your last answers. @kahliburke already said it more bluntly than I will:
it’s mostly due to your attitude towards others in the Julia community. It does not inspire that spirit.
In your defense you listed your contributions to SymEngine.jl and your bug reports to SymPy.jl, and you announced:
rolling out local LLMs which hopefully should improve the handling rate on ‘simple’ PRs
That confirms the ingestion pipeline better than anything I could have written: the plan for the review queue is to hand it to language models. My #1843 is not a simple PR, and I suppose that is why it has been waiting 202 days. On Giac you wrote:
we should interface with the new Giac.jl stuff more but haven’t gotten to it.
Chris, I am the new Giac.jl stuff. The interface you haven’t gotten to is a review queue with my name on it, open since April. As for Giac being fairly restricted: a CAS is not restricted because it does not do SciML. John uses Giac as both the coverage reference and the speed reference in the very reports you dismiss as treating this as a competition. It seems comparisons only count as competition when they don’t flatter.
So, to answer the original question: yes, there is a reason to not take an open source approach and collaborate. I have been trying to, in your own repositories, since April. From where I stand, collaboration here is something you request and do not practice.
One last thing, because in the end it is the real answer to your question. Open source runs on volunteers. Nobody owes Symbolics.jl a pull request: not John, not me, not anyone. The same freedom that lets you set the direction of your projects lets each of us decide where our unpaid evenings go, whether into a review queue or into GruntzLimits.jl, RischIntegrate.jl, SymJ.jl, Giac.jl and OpenSymbolicRules. When a maintainer treats volunteer PRs as an inbox that can wait 200+ days, contributors who build their own packages are not defecting. They are using the freedom that makes open source work. We are volunteers, not an unpaid backlog.
The first pull request is somewhere. It has been there for 202 days. Token waste, indeed.