For years, the 3D printing industry has been struggling with fragmentation: numerous file formats, a variety of interfaces, and closed ecosystems controlled by manufacturers. In such an environment, the idea of creating a universal platform – something like an “Android for 3D printing” – sounds tempting.
But does yet another, no matter how ambitious, project really stand a chance of solving these long-standing problems?
I decided to take a closer look at the concept of AMOS (Additive Manufacturing Operating System), analyzing two approaches – the historical Spark project developed a decade ago by Autodesk, and the company’s current approach to integrating AM slicers within Fusion 360.
Is one grand platform truly a functional solution, or merely a dream too big for the market?
What Would the “Android of 3D Printing” Really Be?
Conceptually, AMOS is not seen as just another slicer but rather as a complete system for managing the 3D printing process. Key features include hardware independence – the ability to handle different technologies (FFF, SLA, SLS, PBF) within a single environment.
The system would enable advanced production automation: task queue management, printer farms, real-time monitoring, and predictive maintenance.
In its intended form, it would act as an integration hub connecting ERP, MES, PLM, and virtual inventories, while also serving as a channel for third-party applications – built more like a “Play Store” for AMOS extensions.
This sounds like a utopian vision that goes far beyond the current state of the industry – requiring heavy investment and the cooperation of many partners.
Autodesk Spark and why “Android for AM” already failed once
Autodesk Spark debuted in May 2014, presented as an open API and cloud-based platform designed to standardize the preparation and delivery of 3D models for printing – regardless of hardware or material.
Autodesk also created Ember – an open SLA 3D printer built on Spark – comparing the move to Android and Nexus: an attempt to create reference hardware to drive platform adoption.
The company even launched an investment fund of up to 100 million dollars to support innovators in the Spark ecosystem.
Despite these ambitious plans, Spark stagnated and was shut down a few years later, including the discontinuation of the Ember printer in 2017.
An analysis of the failure points to several causes. First, there was a lack of interest from hardware manufacturers – industry leaders such as Stratasys and 3D Systems had no incentive to support an open standard that would let customers operate independently of their ecosystems. Smaller companies, on the other hand, feared losing control over the “soul” of their machines.
It was the classic “chicken-and-egg problem” – without printers, developers wouldn’t come, and without developers, the platform had no value.
In addition, Autodesk, as a software company, naturally competed with hardware manufacturers, creating a conflict of interest. Overall, Spark demonstrated that industry politics and market protection were stronger than the technological idealism behind the plan.
An alternative model: integrated “Command Centers” like Autodesk Fusion 360
Today, instead of moving toward an open operating system, the industry is gravitating toward comprehensive, integrated CAD/CAM platforms. Autodesk Fusion 360 is a prime example of this approach – a system that combines design, simulation, production preparation, and even 3D printing in one environment.
With extensions such as Fusion Manufacturing Extension, Fusion offers advanced tools – from 4- and 5-axis machining, through nesting, to metal AM with thermal simulation and support structure generation.
The platform also integrates generative design, simulation, and print preparation for technologies such as FFF, SLS, MJF, PBF, and DED. It even allows print outsourcing through applications like Xometry and provides a broad library tailored for different printers.
This model provides a smooth workflow from design → optimization → production within a single, unified ecosystem.
It eliminates the need to transfer data between separate systems and allows for automation and centralization of work.
However, it still remains a closed solution – Autodesk’s proprietary system – which limits interoperability with external solutions.
Does AMOS make sense at all?
When considering the value of AMOS, one must weigh both its potential benefits and its very real limitations.
The advantages are largely rooted in a utopian vision of efficiency – theoretically enabling maximum automation and full visibility of the production process from design to finished print.
Large enterprises could benefit from a single system to manage an entire, diverse fleet of machines. An open API could also stimulate the development of niche applications and innovation.
On the other hand, standardization seems highly unrealistic – the technological differences between, say, FFF, metal binder jetting, and MJF are vast and require completely different control strategies.
Hardware manufacturers will protect their solutions – this is their know-how and source of competitive advantage. The costs and complexity of building such a system are astronomical – measured in years of work and hundreds of millions of dollars.
And then there’s the issue of security: one central platform becomes an attractive target for cyberattacks.
Finally, one must ask: does the market even need this? Many companies are already developing their own integrations with MES and middleware solutions, which in practice is sufficient.
Dream vs. reality
The AMOS concept is a beautiful utopia – an idea that promises maximum automation, democratization of production, and interoperability.
But the Spark story showed that attempting such a project runs counter to the structural interests of the industry. Beyond that, the technological diversity, cost, and risks make it an extremely difficult undertaking.
The real evolution of the industry will likely come through the development of existing APIs (such as Dyndrite), platforms like Fusion 360, and the gradual adoption of communication standards (for example, OPC UA in IIoT).
Instead of one ideal “Android,” we will probably see a federation of specialized tools that slowly learn to work together.
In conclusion – does 3D printing need its own Android? To want – certainly. To need – maybe. To actually get – that’s a much more complicated story.