The Changing Economics of Software
The rise of agentic AI in software development, especially through vibe-coding, has become one of the defining discussions in the software industry. Increasingly, however, a related development is beginning to attract attention: the use of AI to reverse-engineer existing software and develop open-source alternatives to established closed-source commercial applications. Developers, including those working independently or with relatively limited resources, are increasingly exploring ways by which AI can make it substantially easier to reproduce the functionality of mature software products.
Open-source alternatives to proprietary software are hardly new. LibreOffice has long offered an alternative to Microsoft Office, while Linux demonstrated that an open-source operating system could become foundational to modern computing. Yet building an alternative and making it a compelling substitute are two different challenges. Mature commercial applications embody years of engineering, interface refinement, compatibility improvements and ecosystem development. Reproducing this breadth of functionality, particularly while maintaining the reliability and polish that users expect, has traditionally required considerable time, expertise and sustained effort. Even when open-source alternatives have offered capable and cost-effective solutions, persuading users to abandon familiar products and established workflows has remained a separate challenge.
That is what makes the current wave of AI-assisted development significant. Projects such as ArtCraft, an open-source creative software initiative seeking to offer alternatives to applications associated with Adobe’s suite, have brought renewed attention to the possibility of developing such alternatives with the assistance of AI. These efforts do not yet establish that AI can reliably reproduce the capabilities of mature commercial software, much less guarantee widespread adoption. They do, however, raise a consequential question: what happens to the economics of open-source software when the cost of understanding, reproducing and improving existing software functionality begins to fall?
The Consumer Adoption Problem in FOSS
Some free and open-source software (FOSS), such as FFmpeg and Linux, has become deeply embedded in digital ecosystems. FFmpeg powers media processing across a wide range of applications, often without the end user ever knowing that it is being used. Linux, meanwhile, underpins much of the internet’s server infrastructure and a broad range of other computing environments. Yet the adoption trajectories of FOSS projects vary considerably. Alternatives such as LibreOffice continue to compete with deeply entrenched proprietary office suites, despite offering many of the same core capabilities without a licence fee.
These examples also reveal an important distinction: software can achieve widespread adoption as an underlying component of other products without becoming the preferred application of end-users. The widespread use of FFmpeg does not require end-users to choose it over a competing product; they may never interact with it directly. Choosing LibreOffice over Microsoft Office, by contrast, requires users to make a conscious decision to switch from an established product and, potentially, change familiar workflows.
The availability of a free and open-source alternative may attract supporters, particularly those who value software freedom, transparency, privacy or lower costs. However, ideological support and initial experimentation do not necessarily translate into sustained adoption. A consumer may appreciate the principles behind a FOSS project, install it and explore its capabilities, yet eventually return to a proprietary alternative if the experience proves inconvenient or incompatible with existing needs.
For FOSS to achieve widespread consumer adoption, therefore, it must offer more than access to its source code or freedom from licence fees. It must compete with established alternatives across the practical dimensions that shape a consumer’s decision to switch and continue using a product.
Elements of FOSS Adoption
Five broad elements can help explain whether a FOSS application can move beyond a supportive niche and achieve sustained consumer adoption:
-
Value proposition
A FOSS alternative must offer an actual, evident and meaningful reason for consumers to switch. This may be superior functionality, lower costs, greater privacy, customisability or a better user experience. Being free and open source is not, by itself, sufficient to persuade users to abandon an established product. -
Ease of adoption
Installation, onboarding and everyday use must be accessible to users with varying levels of digital literacy and technical expertise. Some consumers may prefer a paid, one-click installation over a free alternative that requires command-line operations, manual configuration or specialist knowledge. A product that is difficult to get started with risks losing users before they experience its benefits. -
Trust and credibility
Consumers must be confident in the software’s security, privacy and provenance. Although FOSS allows its source code to be inspected, source-code availability alone does not guarantee that an application is safe, nor does it mean that ordinary users can independently verify its security. Transparent privacy practices, credible release channels, verifiable updates and a visible record of maintenance help establish trust. -
Interoperability and ecosystem fit
A FOSS alternative must enable users to migrate their existing files, projects and workflows with minimal disruption. Compatibility with established formats, applications, plugins and collaboration networks is particularly important. Until users can reliably transfer their work and perform their everyday tasks in the alternative, they may remain trial users rather than complete adopters. Where a thriving ecosystem already exists, the ability to integrate with it may be more valuable than attempting to replace it entirely. -
Sustained development
Consumers need confidence that the software will remain usable and dependable over time. Predictable releases, timely bug fixes, security updates, relevant feature improvements and continuity of maintenance signal that the project is a sustained effort rather than a one-off experiment. Without this confidence, even a capable application may struggle to persuade users to depend on it for their everyday work.
These five elements are not entirely independent. Trust, for instance, is also reinforced by sustained maintenance, while interoperability can determine whether an otherwise compelling value proposition translates into a successful switch. Together, however, they provide a useful framework for examining the gap between the availability of a FOSS alternative and its adoption at scale.
Other factors, including local-language support, accessibility, device compatibility and the availability of localised documentation, can also influence adoption. These are best understood as cross-cutting requirements that affect the five elements, particularly ease of adoption, trust and ecosystem fit.
What Agentic AI Changes
The five elements outlined above are not easy to achieve. For many, even one of them can represent a substantial engineering challenge; addressing all five while competing with an established commercial product can be an undertaking of considerable scale. Agentic AI is beginning to change this equation. Developers and vibe coders across the world are using AI agents to build, test and refine software at a pace that was previously difficult to achieve without a larger team or substantial resources.
More importantly, developers are increasingly able to address the friction they experience as users themselves. A developer who finds an existing application difficult to use, unnecessarily expensive or incompatible with a preferred workflow can now attempt to build an alternative. What begins as an individual problem may turn out to be a problem shared by thousands or millions of other users. This creates the possibility of a consumer-led value proposition: instead of starting with a market opportunity identified by a large commercial developer, an alternative emerges from a user’s own experience and is refined with the assistance of AI.
This is where agentic development intersects with reverse engineering. By studying the observable behaviour, interfaces and file-format compatibility of existing applications, developers can attempt to reproduce useful functionality in an independently developed implementation. AI agents can assist with translating those observations into code, generating tests, diagnosing discrepancies and iteratively improving the result. The objective is not simply to produce a working application, but to reduce the effort required to create an alternative that users can readily understand and adopt.
The open-source image editor GIMP illustrates the distinction between technical capability and ease of adoption. Although it offers extensive image-editing functionality, its interface and workflows differ from those of Adobe Photoshop. Users accustomed to Photoshop may therefore face a learning curve when switching to GIMP. This does not mean GIMP is inherently inferior, nor that all users find it difficult; it illustrates how differences in familiar workflows can become a barrier to switching.
PhotoCraft, developed as part of the ArtCraft initiative, takes a different approach. It is an open-source image editor written from scratch in Rust, with an interface designed around familiar Photoshop conventions, including menus, panels and keyboard shortcuts. It also aims to support layered Photoshop documents. Its developers describe the implementation as a clean-room reimplementation based on public specifications and observed behaviour rather than proprietary Adobe code. The project is available under permissive open-source licences.
This approach addresses two elements of FOSS adoption simultaneously. First, it offers a value proposition to users seeking a free, locally runnable alternative to subscription-based software. Second, by preserving familiar interaction patterns and supporting existing file formats, it attempts to lower the cost of switching. Users need not necessarily relearn their entire workflow before they can begin working with the alternative.
The significance of this example lies less in whether PhotoCraft has already achieved parity with Photoshop—it has not—and more in the development model it represents. AI-assisted development makes it possible to attempt a complex, familiar-feeling alternative without first assembling a traditional large engineering team. The resulting product can then be tested, improved and expanded through successive iterations. Recent independent reviews nevertheless identify important gaps in functionality, stability and professional workflow support, underscoring the distance between an early alternative and a mature commercial product.
The implications become more significant when the ambition extends beyond a single application. Adobe Creative Cloud is not merely a collection of standalone tools: it connects applications for image editing, illustration, video production, photography and page layout within a broader commercial ecosystem. Replacing Photoshop alone does not reproduce the convenience of having an integrated suite of creative tools.
ArtCraft’s wider initiative includes projects such as PhotoCraft, VectorCraft and FilmCraft, intended as alternatives to Photoshop, Illustrator and Premiere Pro respectively. This represents an attempt to develop a family of applications rather than an isolated substitute.
The distinction matters because ecosystem fit is one of the five elements of FOSS adoption. A consumer who depends on several applications may be reluctant to switch if doing so requires abandoning familiar workflows or assembling a disparate collection of alternatives. A coordinated suite can potentially offer common interaction patterns, distribution and maintenance, reducing some of these barriers.
Agentic AI may also help address the problem of sustained development. Open-source projects often depend on a limited number of maintainers who must divide their time between new features, bug fixes, documentation, security updates and user support. As a project grows, this workload can become a constraint on its development and reliability.
AI coding agents can assist with discrete maintenance tasks: analysing bug reports, reproducing errors, suggesting fixes, generating regression tests, updating documentation and preparing changes for review. They can also help developers respond to recurring user requests and implement incremental improvements. Tools such as GitHub Copilot’s coding agent demonstrate how issues can be delegated to an agent that modifies a codebase and submits a pull request for human review.
For FOSS, the potential benefit is not merely faster feature development. More responsive maintenance can help projects remain reliable, address user frustration and demonstrate that the software is actively supported. This may improve the likelihood that consumers continue using an alternative rather than returning to an established product.
These capabilities, however, do not eliminate the need for human oversight. AI-generated changes can introduce regressions, security vulnerabilities or unnecessary complexity. A project that produces features faster than its maintainers can verify them may accumulate technical debt rather than become more sustainable. Agentic AI can reduce the cost of maintenance work, but it cannot by itself guarantee responsible governance or long-term commitment.
The Limits of AI: Trust Remains a Separate Challenge
Trust is perhaps the most complicated of the five adoption elements in this new development model. AI can help produce privacy documentation, automate security tests and make development practices more transparent. Yet it can also generate code whose behaviour the developer does not fully understand, making independent verification particularly important.
Nor should consumer trust be reduced to whether software was written by humans or AI. Most ordinary users cannot personally audit a large codebase, regardless of who wrote it. They instead rely on signals such as a credible developer, reputable distribution channels, predictable updates, independent reviews and a history of responding to security issues. AI-assisted projects must establish these signals just as other software projects do.
The resulting tension is significant. Agentic AI may make it easier to build and distribute alternatives, but the resulting abundance of new applications could make it harder for consumers to distinguish mature, dependable products from experimental projects. Transparent development, reproducible releases where feasible, independent testing and clear disclosure of limitations will therefore remain essential.
Taken together, these developments suggest that agentic AI can help developers address several barriers to FOSS adoption simultaneously: it can reduce the cost of building a compelling alternative, improve onboarding and compatibility, and assist with ongoing maintenance. The extent to which these capabilities translate into sustained consumer adoption remains an empirical question. The next challenge is to move from individual AI-assisted projects towards a more systematic approach to developing and sustaining open-source alternatives.
REA: Towards an Agentic Open-Source Ecosystem
Reverse engineering is the process of examining an existing system to understand how it works, to the extent that its functionality can be independently rebuilt. Traditionally, this has required considerable technical expertise. Developers may need to inspect executable files, analyse program behaviour, trace function calls, examine file formats and use specialised tools to infer how a particular feature operates. Agentic AI is beginning to change how this work can be undertaken.
Reverse Engineer Anything (REA), developed by morluto, offers an early example of this emerging approach. REA is an open-source toolkit that connects AI coding agents to reverse-engineering capabilities through a command-line interface and the Model Context Protocol (MCP). Rather than relying entirely on a developer’s manual, complex, and time-taking investigation, an AI agent can use REA to inspect supported applications and binaries, trace relevant code and produce findings that help explain how particular features work. The agent can then use that evidence to implement and test an independent version of the feature.
Consider a simple example. A user encounters a desktop application that converts a DOCX document into a PDF with a single click. They would like to implement the same capability in their own application. Without access to the original source code, understanding the feature may require investigating how the application processes the document, which libraries it uses, how it handles formatting and fonts, and how it generates the resulting PDF.
With a suitable target and investigation workflow, REA can help an AI agent inspect the available program artefacts, trace relevant functions and recover useful evidence about the implementation. The agent can then use these findings to develop a separate DOCX-to-PDF converter, test it against representative documents and refine the implementation when differences emerge.
This does not mean that REA can automatically reproduce any feature in any application. The depth of analysis depends on the target, the available artefacts and the tools required to inspect them. Nor does reverse engineering necessarily reveal every detail of an application’s behaviour. The important development is that REA provides an agent with a more systematic means of investigating existing software, instead of requiring the developer to conduct every step manually.
The implications for FOSS could nevertheless be substantial. If agentic tools reduce the effort required to understand existing software, independent developers may be able to build alternatives to features that were previously expensive or difficult to reproduce. Rather than starting with a blank page, they can investigate an existing implementation, establish what it does, identify the behaviour worth reproducing and construct an independent implementation suited to their own requirements.
The resulting opportunity extends beyond individual features. A developer could investigate several applications, identify common functionality and build a coherent set of open-source alternatives around a particular category of work. AI agents could subsequently assist with compatibility testing, documentation, bug fixing and maintenance. In this sense, REA is not itself an open-source application suite; it is an enabling tool that could help developers create and sustain such suites.
There are, however, important boundaries. Reverse engineering must respect applicable laws, licence conditions and intellectual-property rights. Reimplementing functionality independently is not the same as copying proprietary source code, and the legality of particular techniques depends on the circumstances and jurisdiction. REA’s own documentation frames its use around lawful research, interoperability, software preservation and the analysis of software that the user owns or is authorised to examine.
The broader significance of REA, therefore, lies in the possibility of bringing reverse engineering into the ordinary workflow of AI-assisted development. If this approach becomes reliable and accessible, the cost of understanding existing software may fall considerably. That could give FOSS developers a new way to address the five adoption barriers identified earlier—not by assuming that AI-generated alternatives will automatically succeed, but by making it more feasible to develop, test and maintain products that can compete on the factors consumers actually value.
Implications for Enterprise Solutions
The emergence of AI-assisted alternatives to established commercial software may offer relief to users frustrated by rising subscription prices, restrictive practices and dependence on proprietary ecosystems. Projects such as ArtCraft and PhotoCraft illustrate the possibility of developing alternatives to applications within Adobe Creative Cloud. However, the availability of an alternative does not automatically translate into migration. Users have invested time in learning existing applications, building workflows, accumulating files and integrating tools into their everyday work. An alternative must demonstrate sustained value, compatibility and reliability before users can confidently make the switch.
The future of AI-enabled FOSS will therefore depend on more than the ability to develop software quickly. Projects will need sustained communities of developers, contributors and volunteers who can test implementations, resolve bugs, review security issues, improve documentation and respond to user requirements. Agentic AI can help reduce that effort, but it cannot, as of now, independently guarantee accountability, sound governance or long-term commitment. The challenge, therefore, is to support the development of dependable software that people can continue to use rather than just creating alternatives.
The legal questions surrounding reverse engineering, intellectual property and software licensing constitute a separate and substantial debate, which this article does not attempt to examine. The focus here is on the technical, organisational and consumer-adoption implications of AI-enabled reverse engineering.
Ultimately, the opportunity presented by REA and agentic AI is not simply that more people can now build FOSS alternatives to commercial software. It is that developers may be able to address longstanding barriers to adoption with considerably fewer resources than before. Whether this translates into lasting change will depend on the ability of projects to move beyond initial functionality, build credible communities and demonstrate sustained value to their users.
Communities as Flagbearers of FOSS
If agentic AI and reverse-engineering tools lower the barriers to creating open-source alternatives, communities will become increasingly important in determining which projects survive beyond their initial development. AI agents may help developers reproduce features, generate code and resolve bugs, but they cannot, by themselves, ensure that a project remains relevant to its users or attracts sustained contributions. Communities provide the collective effort needed to test software across different environments, identify shortcomings, review proposed changes, improve documentation and shape development around actual user needs. They also help build credibility through transparent development, peer review and a visible record of maintenance. As AI makes it easier to create new applications, the challenge may no longer be simply to produce working alternatives, but to identify and sustain those that genuinely serve users. The future of AI-enabled FOSS will therefore depend not only on what individual developers and AI agents can build, but also on whether communities can turn these early projects into dependable, evolving and widely adopted software.
Conclusion
Agentic AI and AI-enabled reverse engineering could mark a significant shift in the economics of free and open-source software. Tools such as REA offer a glimpse of how developers may be able to investigate existing software, understand its functionality and build independent alternatives with fewer resources than were previously required. Initiatives such as ArtCraft further illustrate the ambition to extend this approach beyond individual applications towards broader alternatives to established commercial software ecosystems.
Yet, reducing the cost of development does not, by itself, resolve the longstanding challenge of FOSS adoption. An alternative must offer a meaningful value proposition, remain accessible to users, earn their trust, fit into their existing workflows and demonstrate sustained development. AI may help developers address these requirements, but it cannot guarantee that the resulting software will meet them. The proliferation of alternatives could create new opportunities for consumers while also increasing the importance of quality assurance, credible maintenance and long-term support.
The decisive question, therefore, is not simply whether AI can make it easier to reproduce the functionality of existing software, but whether it can help make dependable alternatives available to a wider range of users. This will require more than capable AI agents and innovative developers; it will also require sustained human oversight, effective collaboration and communities willing to improve and maintain the software they create. If these elements come together, AI-enabled reverse engineering could do more than increase the number of open-source applications. It could expand the range of viable choices available to consumers and make the FOSS ecosystem more competitive in areas long dominated by proprietary software.
- morluto. (2025). REA: Reverse Engineer Anything. GitHub Repository.
- Thomas, Brandon. (2025). PhotoCraft: Clean-Room Image Editor Reimplementation in Pure Rust. GitHub Repository.
- ArtCraft Initiative. (2025). ArtCraft: Open-Source Native Creative Suite.
- Karpathy, Andrej. (2025). On Vibe Coding and System-Level Software Direction. X (formerly Twitter).
- Anthropic. (2024). Model Context Protocol (MCP) Specification. Anthropic / Linux Foundation.
- GitHub. (2024). Next-Generation Developer Workflows with GitHub Copilot Workspace and Autonomous Agents. The GitHub Blog.
- Electronic Frontier Foundation (EFF). (2023). Coders’ Rights Project: Reverse Engineering FAQ. San Francisco: EFF.
- United States Court of Appeals for the Ninth Circuit. (2000). Sony Computer Entertainment, Inc. v. Connectix Corp., 203 F.3d 596 (9th Cir. 2000). Legal Information Institute, Cornell Law School.
- Federal Trade Commission (FTC). (2024). FTC Takes Action Against Adobe and Executives for Hidden Fees and Deceptive Subscription Cancellation. Washington, D.C.
- Eghbal, Nadia. (2016). Roads and Bridges: The Unseen Labor Behind Our Digital Infrastructure. New York: Ford Foundation.
- Lerner, Josh, and Jean Tirole. (2002). Some Simple Economics of Open Source. The Journal of Industrial Economics, 50(2), 197–234.
- The Document Foundation. (2020). LibreOffice Migration Guide: Transitioning from Proprietary Suites in Public and Enterprise Sectors. Berlin.