What if the future of engineering software was visual, open, and built for the modern world?
For decades, LabVIEW proved something important to the engineering world: programming does not have to be limited to syntax.
That idea was never trivial.
It was not a curiosity.
It was not a shortcut.
It was a profound insight.
In many engineering domains, seeing the flow of data is often the most natural way to think, design, validate, and build. National Instruments helped demonstrate that to generations of engineers, researchers, and system architects. That achievement is real. It is significant. And it deserves respect.
But great ideas do not lose value with time.
They ask to be carried further.
Today, software ecosystems are different. Compiler infrastructures are more mature. Open-source collaboration moves faster. Hardware diversity is wider. Expectations around interoperability, transparency, accessibility, and long-term portability are higher than ever.
So the question is no longer whether graphical programming has value.
The real question is this:
What would a modern open graphical language look like today?
At Graiphic, after a long period of reflection, we decided to take that question seriously.
And that is why we are launching FROG — Free Open Graphical Language.
Why we are launching FROG
FROG was not born from fashion.
It was not born from nostalgia either.
It was born from a conviction: graphical programming remains one of the most powerful ways to express complex systems, but its future should not depend on closed boundaries alone.
For years, the software world has benefited from open languages, open toolchains, open compiler infrastructures, open runtimes, open file formats, and open collaboration models. These foundations accelerated innovation, broadened adoption, and enabled ecosystems to grow far beyond any single vendor or product.
Graphical programming deserves that kind of future too.
We believe the core promise of graphical development is still extraordinary: making architecture more visible, behavior more intuitive, and software more aligned with the way many engineers actually think.
But to meet the demands of the modern world, that promise needs new foundations.
It needs to be more open.
More portable.
More inspectable.
More interoperable.
More ambitious.
That is the spirit behind FROG.
What FROG is
FROG is an open-source initiative exploring a new generation of graphical programming.
Its goal is to help define an open graphical dataflow language that is:
-
accessible enough to lower unnecessary barriers,
-
rigorous enough to support serious engineering,
-
ergonomic enough to be enjoyable to use,
-
hardware-agnostic enough to avoid artificial lock-in,
-
and ambitious enough to grow far beyond prototyping.
We are not interested in building a toy.
We are not interested in building a visual gimmick.
We are not interested in reproducing yesterday’s constraints with a fresh coat of paint.
FROG is about creating a foundation for a new class of tools and workflows: software for prototyping, monitoring, orchestration, industrial systems, instrumentation, interaction-heavy applications, and eventually the control of highly complex mission-critical environments.
That ambition is large.
Intentionally so.
Respecting the past, building the next chapter
It would be easy to frame innovation as opposition.
That is not our view.
LabVIEW and National Instruments accomplished something remarkable: they proved, in the real world, at industrial scale, that visual programming can be powerful, productive, and deeply relevant to engineering. That contribution helped shape how countless people think about test, measurement, automation, control, and system design.
That legacy matters.
But respecting what came before does not mean standing still.
It means recognizing that the underlying idea was bigger than any one era of software.
The idea was right.
The world has evolved.
Now it is time to carry that idea forward into a new generation of open tooling, modern architectures, and broader accessibility.
FROG is not a rejection of what graphical programming achieved before.
It is an attempt to honor its core insight by giving it room to evolve.
Why now is the right moment
There are moments when a technical challenge stops being merely interesting and becomes necessary.
This feels like one of those moments.
Engineering software is becoming more complex, more connected, more distributed, and more multidisciplinary. Systems now span local hardware, edge devices, cloud services, AI pipelines, orchestration layers, interfaces, monitoring dashboards, and increasingly heterogeneous execution environments.
At the same time, teams need tools that make system behavior easier to reason about, not harder. They need development models that help expose architecture instead of burying it. They need workflows that can be understood not only by syntax specialists, but also by system engineers, domain experts, researchers, and technical collaborators.
The modern world does not need less structure.
It needs clearer structure.
And in many contexts, visual dataflow remains one of the most compelling ways to express that structure.
That is why now feels like the right time.
Not because the challenge is easy.
Because the challenge is worth taking on.
The real challenge is bigger than the runtime
When people think about building a language, they often imagine the compiler or the runtime as the hardest part.
Those parts matter, of course.
But for a project like FROG, the challenge is even broader.
The IDE matters.
The editing model matters.
The graph interaction model matters.
The visual ergonomics matter.
The user experience matters.
The way humans navigate complexity matters.
Graphical programming lives or dies not only by its execution model, but by the quality of interaction between the human mind and the system being built.
That means the hard problem is not only “how do we execute this?”
It is also “how do we make visual development truly scalable, intelligent, intuitive, and rigorous?”
That is a colossal design space.
And that is exactly why it is interesting.
Our ambition
Our ambition is not to build just another tool.
Our ambition is to help lay the foundation for an open graphical ecosystem where engineers, developers, researchers, and creators can innovate freely.
An ecosystem where the language is not trapped inside one closed implementation.
An ecosystem where tools can evolve.
An ecosystem where source representations are transparent.
An ecosystem where visual programming can be treated with the seriousness usually reserved for major textual languages.
We want to contribute to a future where graphical programming is not seen as a niche exception, but as a credible, modern, extensible way to build demanding software systems.
That is a long road.
But meaningful foundations are always long-term projects.
Why openness matters so much
Openness is not a decorative feature for FROG.
It is one of the central reasons the project exists.
Open foundations create trust.
They create longevity.
They create interoperability.
They create room for experimentation.
They create the conditions for ecosystems rather than silos.
When a programming model is powerful, it should be allowed to grow through shared scrutiny, shared contributions, and shared implementation effort.
That is especially true for graphical programming, which has often been appreciated for its power while remaining too constrained by proprietary boundaries.
We believe a new generation of visual engineering software should be able to stand on foundations that are open enough to endure.
That is what FROG is trying to make possible.
Thinking beyond today
The immediate work is hard enough already: defining the language, the representations, the interaction models, the execution semantics, the development architecture, and the long-term technical coherence of the ecosystem.
But we are not thinking only about today.
We are thinking about the systems engineers will need tomorrow.
We are thinking about software that coordinates machines, instruments, robots, industrial platforms, distributed infrastructure, intelligent monitoring, adaptive workflows, and highly demanding operational environments.
And yes, if one day ideas like these help orchestrate software in the kinds of systems that make people think of NASA, that would not feel absurd to us.
Because powerful engineering tools should not be designed only for the limits of the present.
They should be capable of growing toward the frontier.
A beginning, not a finished claim
FROG is now launching as a development effort.
That distinction matters.
This is not the announcement of a finished universe.
It is the beginning of a serious undertaking.
We are stepping into a difficult problem with open eyes.
Language design is difficult.
Tooling design is difficult.
Visual interaction at scale is difficult.
Building something truly useful is difficult.
But some challenges deserve to be approached precisely because they are difficult.
FROG begins there.
With ambition, yes.
But also with humility toward the size of the work ahead.
Why this matters
Because programming is not only about telling machines what to do.
It is also about giving humans a better way to think.
And when systems become more complex, the quality of that thinking interface matters enormously.
Graphical programming has already shown that it can change the way engineers understand software.
Open ecosystems have already shown that they can change the way technology evolves.
FROG stands at the intersection of those two truths.
That is why we believe this matters.
Join the beginning
This is the start of the journey for FROG.
If you believe the future of engineering software can be more visual, more open, and more structurally expressive, we would be glad to have you follow the project, talk about it, challenge it, and help it grow.
Because ideas like this only become truly useful when a community forms around them.
And the faster people discover the project, the faster that community can emerge.
We are building FROG in the belief that graphical programming still has immense untapped potential.
Not as a relic.
Not as a niche.
But as part of the future.
𝐆𝐢𝐭𝐡𝐮𝐛 & 𝐎𝐩𝐞𝐧 𝐒𝐨𝐮𝐫𝐜𝐞 𝐏𝐫𝐨𝐣𝐞𝐜𝐭𝐬
👉 https://lnkd.in/ecRrkH4w
