Hi,
I’m currently working with my students (BUT3 GEII in France) with OpenModelica and wonder when / if a similar GUI is planned. I can provide some educational examples in the field of mechatronics / electrical engine sizing.
Best regards
The GUI will be released very soon.
6 Likes
Any plans of adding EN 50716 to this list? This would cover a significant share of the world’s railway business and should only be a small addition when the three standards above are covered. It might be mostly the stamp which is needed, but we all know that this can make all the difference in the world.
If we have a champion in the industry that can help us navigate entering that space, definitely get in touch and we will map it out.
5 Likes
PM sent.
1 Like
Extremely promising work — keep it up! 
I may have missed something, but the items below still look open to me.
Could you clarify?
-
Formal language specification
Modelica has a published, versioned PDF spec.
Q: Will Dyad provide a publicly maintained language spec so that others could, in principle, write a second compiler? -
Open-source licence for the tool-chain
The current Source-Available licence blocks commercial use without a paid seat.
Q: Is an OSI-approved licence or a free “community edition” on the roadmap? -
Pricing transparency for small teams / single seats
The website shows only the five-seat “Team” bundle (~ US $25 k / yr).
Q: Will standalone seat pricing be published (or a public price list in general)?
Coming from the Modelica world, Dyad’s modern design is very appealing —
but understanding the long-term openness story would make adoption decisions much easier.
Thanks in advance for any guidance!
7 Likes
We are not planning a formal spec. Our focus is on creating the best possible combination of high-level modeling capabilities built on a Julia foundation. It takes a LOT of energy to write specs and make alternative implementations. We want to focus our energy exclusively on delivering impactful tooling.
The source available license is the only license planned. We are pouring a lot of resources into the development of Dyad. This not only applies to development, but infrastructure, training material, support, etc. Note that for personal projects and academic projects, there exist “free” options. But for commercial applications, you do have to pay for the tools. This may look expensive compared to open source alternatives but we’ll see how the market responds. We feel Dyad really provides the best of both worlds. You get access to the source but you also get the resources of a commercial product when you are doing commercial work yourself (and, as I said, when you are doing research or personal projects, you have free options).
As for pricing, someone from our sales organization would need to comment on that.
7 Likes
As @michael.tiller said, producing a formal language spec is a lot of work. Moreover, I’m not sure we want there to be alternative implementations. As with Julia, we want there to be one really good implementation that everyone can use. The source available license means that people who are just doing research or personal work don’t have to pay; people that are using it for commercial purposes presumably can and should pay.
@gwr, I’d love to hear why you want a spec so that an alternative implementation could be created, and also why an open source tool chain would be desirable as compared to having it be source available. My guess is that it would help provide assurance that if you come to rely on it and it ceases to be offered or maintained commercially, you’re not stuck in a bad situation. If that’s the concern, that makes a lot of sense, but I think there are other ways to ensure that. Off the top of my head, we could (hypothetically) contractually ensure that if the company goes away or stops offering Dyad commercially, that we will release the Dyad tool chain as open source. But I’m just guessing at why you’re asking about this when you could just tell me, so maybe that’s not it at all.
5 Likes
That would be great — I’ve seen too many cases where a product is cancelled (or a company is acquired etc.) in which software disappears into a black hole, never to be seen again.
For example, some of you may remember a little package called Star-P, which was acquired by Microsoft and vanished.
18 Likes
The pricing on the website is for JuliaHub - we haven’t yet put Dyad pricing on the website. We are still working through the pricing model and conversations with potential customers are helpful. It will be transparent and on the website once we form a view.
If you can email us at sales@juliahub.com, our sales team will be happy to discuss and quote you standalone seat as well.
-viral
4 Likes
Thanks for the clarification, I’ll pick this up in a slightly more elaborate post explaining where I am coming from.
In spring (it was still JuliaSim time), I did exactly that and never received any reply. That’s when I started “harassing” @michael.tiller and @ChrisRackauckas via direct messages here and on LinkedIn. 
4 Likes
Yes sorry I think that was my bad on the communication there. I had discussed with a few folks about what was then the JuliaSim modeling language and what was going on with the GUI, which had a few features that were being asked for. I mentioned we should re-engage when the big release happens. Now is that time 
. Definitely let’s follow up, but please use the sales email as that will get it tracked and onto the calendar (with people poking me to respond) while my linkedin is a portal with a few hundred spam messages where things will get lost.
3 Likes
Thank you @michael.tiller, @viralbshah, and @StefanKarpinski for the detailed replies so far. Two contractual and two deployment questions remain for me.
My use-case and background
I’m the author of the Business Simulation Library (BSL) for Modelica, which uses acausal connectors for causal system dynamics models in a neat way (@Michael.tiller 's book got me started). Currently, I am working on an extended version called Acausal System Dynamics (AcausalSD™), which
- adopts Modelica’s synchronous-time framework for discrete behavior,
- offers classes for truly acausal modeling of economic systems grounded in a bond graph approach.
My Modelica tool of choice is Wolfram System Modeler, which currently is unique in its support of more flexible units and smart unit checking (in economic models we need years as a displayUnit, discrete counts like each, and money as a non-SI-unit.
The reality of FOSS monetization
Dual licensing (AGPL-3 + commercial licence) is the only viable way for indie library authors who are not in academia.
I’m happy to pay for tooling the moment corporate users pay for my work, but seat prices that ignore the value a library brings back to the ecosystem feel unbalanced.
Vendor lock-in concerns
@StefanKarpinski kindly floated the idea of an open-source trigger if JuliaHub ever drops Dyad. That helps, but day-to-day risks remain:
- Q1: Can commercial contracts include a price-cap clause and block forced tier migrations?
- Q2: Will perpetual fallback licenses be offered so we can keep using the last paid version if future pricing becomes prohibitive?
Cloud independence & EU data sovereignty
Many EU customers refuse to put their data on servers subject to the US CLOUD Act (for good reason imo).
- Q3: Can Dyad Studio and CLI be licensed for fully offline, air-gapped use?
- Q4: Is an EU-only JuliaHub region (operated by an EU-incorporated entity) on the roadmap?
Answers on these four points will help me decide whether I invest in a Dyad seat now or stay on my all-FOSS Modelica → Julia workflow for the moment. Thanks again!
14 Likes
These are great questions. Thanks for sharing them.
I hadn’t considered the possibility of continuing to sell licenses but at an absurdly high cost, effectively discontinuing the commercial offering for all practical purposes. To be clear, we wouldn’t do this, but companies do get acquired and then sometimes even sold/acquired again, so it makes sense to want to protect against this kind of bad behavior even if you trust the current Dyad team.
I wonder if we could do some kind of “eventually open source” license, where old versions become open source at some point in the future. That seems like it could help address both Q1 and Q2…
The US Cloud Act concern is also legitimate. Dyad Studio is entirely local, so this isn’t an issue for it. Dyad Builder—which is our name for the soon-to-be-released web-based GUI—is hosted on JuliaHub, so this is a concern for that. However, we already have on-prem, self-managed, and air-gapped options for JuliaHub—we have a lot of customers who are very protective of their code and data. I’m not sure how much of this Dyad Builder will support in its initial release, but longer term it will work on all variants of JuliaHub. We’re also not against offering a local version of Dyad Builder if that’s what the market wants, it’s just not what we’ve developed first.
17 Likes
Thanks for the clarifications, Stefan.
They help, but the main strategic worry is still hanging:
Open modelling in Julia must not become collateral damage in the push for a slick, vendor-controlled ecosystem.
Wouldn’t right now every fresh component library have to run through Dyad if we want
- the shiny SVG GUI
- the “official” standard libraries
- first-class Julia/SciML hooks?
In Modelica I have a choice of proprietary and open tools; competition can “do its thing” in principle.
To me the lock-in worries still remain valid:
- Spec—Without a public spec (or at least a living “grammar” documentation) how can anyone ever write an open compiler?
- Open ModelingToolkit libraries—What stops today’s MIT/BSD ModelingToolkit libraries from quietly sliding behind that paywall?
- Governance—How do we make sure Dyad complements, but not dictates the future of Julia modelling?
- FOSS author seat—Is there any chance for seat fees getting waived (or heavily discounted) for developers who ship their libraries under OSI licences?
5 Likes