We have seen what Artcraft has done, we are witnessing what REA (Reverse Engineers Anything) is doing and what people are doing with REA to closed source software/Apps. So how do you see all these and how it is going to affect big corpos with their proprietary closed source software/Apps and how thi […]
Hi Brahman. My view is that
paid software is not disappearing over the next year or two, and everything will certainly not become open source. What is weakening is the idea that a downloadable application's main defence is simply “the source is secret and it took years to write.”
What ArtCraft and REA actually demonstrate
ArtCraft is impressive mainly because of the
speed and breadth with which substantial alternatives can now be produced. But its own PhotoCraft documentation calls the application an early alpha and explicitly says it is not yet a Photoshop replacement for daily professional work. Its dated roadmap estimated roughly 45% readiness for real work, while identifying performance, file-compatibility, workflow and bug-backlog gaps. That is remarkable progress, but it is not “Adobe was recreated over a weekend.”
REA is also more accurately described as an
agent interface to reverse-engineering tools and workflows, not a magic source-code extractor. For native programs it can obtain pseudocode, assembly, strings and references through tools such as Ghidra, Hopper or IDA. For Electron, JavaScript and .NET applications it may recover considerably more structure. The agent then has to interpret the evidence and implement and test an equivalent feature.
It generally cannot recover the original comments, design decisions, test suite or exact source architecture. Nor can it recover a cloud service's private backend merely by examining the desktop client. In short, REA gives reverse engineers very effective power steering; it does not repeal software complexity.
ArtCraft and direct binary analysis are also different factual and legal situations. ArtCraft describes PhotoCraft as a clean-room implementation based on public specifications and observed behaviour, with no proprietary code or assets. That is the project's claim, not an independent legal ruling. Reverse engineering can be legitimate for interoperability, security research and preservation, but copied code or assets, access-control circumvention, licence terms and jurisdiction can change the position considerably; the EFF reverse-engineering FAQ gives a useful US-focused overview.
Where I expect the pressure
| Software category | Likely effect in the next 12–24 months |
|---|
| Simple utilities and “wrapper” apps | Severe price pressure; many features will be cloned or generated quickly |
| Mature professional desktop suites | Better open alternatives, but no sudden mass replacement due to compatibility, plug-ins, reliability and workflow depth |
| SaaS and collaborative platforms | Less exposed to binary reconstruction because much of the product remains server-side |
| Small specialist applications | Both opportunity and danger: much cheaper to build, but also cheaper for a competitor to imitate |
| Enterprise software | Paid products remain strong because customers buy support, compliance, integration, liability and predictable maintenance |
People do not only pay for possession of code. They pay because a product:
- opens their existing files correctly;
- does not lose a week's work;
- integrates with colleagues and established workflows;
- receives dependable security updates;
- comes with accountable support;
- meets compliance and procurement requirements;
- will probably still exist in five years.
Generating a large codebase is becoming cheap.
Maintaining responsibility for that codebase is not. GitHub may acquire endless new repositories; it has not acquired endless competent maintainers.
The future for developers
Developers will still have a future, but the value will shift away from typing routine implementation and towards:
- domain knowledge and good product decisions;
- architecture, testing and security;
- compatibility with real-world files and systems;
- user experience and accessibility;
- deployment, support and incident response;
- community and ecosystem management.
For independent developers, the sensible response is not to wage an unwinnable obfuscation contest. Assume code delivered to a customer's machine can eventually be studied. Keep secrets out of client applications, secure the update channel, sign releases, and build value in areas that are harder to reproduce than a menu layout.
Business models will probably become more varied: open-core products, paid official builds, hosted collaboration, enterprise support, plug-ins, paid upgrades and reasonable perpetual licences. Subscriptions backed by continuous cloud costs and service can survive. “Subscription because we found the billing button,” rather less so.
There is also a security downside to the coming clone boom. Open source does not automatically mean reviewed, and a fashionable replacement application is an excellent disguise for malware. Users should prefer official repositories and signed releases, examine permissions and update mechanisms, and test immature applications with copies of their files—preferably in a VM when provenance is uncertain.
So my conclusion is:
software is not over; code is becoming abundant. Paid applications whose only moat is hidden implementation are vulnerable. Products whose value is trust, reliability, compatibility, service and an ecosystem will continue to earn money, whether their source is open or closed.
Sources
