Hacker News Reader

> The better you document your work, the stronger contracts you define, the easier it is for someone to clone your work.

Well said; this is my thinking as well. One person or organization can do the hard work of testing multiple approaches to the API, establishing and revising best practices, and developing an ecosystem. Then once things are fairly stable and well-understood, another person can just yoink it.

I have little empathy for Vercel, and here they're kind of being hoist by their own petard of inducing frustration in people who don't use their hosting; but I'm concerned about how smaller-scale projects (including copyleft ones) will be laundered and extinguished.

> Then once things are fairly stable and well-understood, another person can just yoink it.

That transparency & availability for community contributions or forks is the point of open-source.

If you're only using open-source as marketing because you're bad at marketing, then you should probably go closed source & find a non-technical business partner.

Whoever "yoinks" the package runs into the same problem because they now have to build credibility somehow to actually profit from it.

Established corporations will be doing yoinking, with a pre-existing credibility. There's a huge incentive to offer these copied services for cents on the dollar, as a way to kill the competition.

Credibility doesn't transfer easily.

Anyone who yoinks an open-source package still has to present an argument about why their offering is better than the original maintainer's.

When push comes to shove, cheapness and hype can shove.

I agree, but it's historically been as simple as "you already use AWS for everything else". For example, ElasticSearch.

It'll be interesting to see if this happens at a service level too. Like how lots of companies offer an S3 compatible API, will companies start offering similar services and building a compatibility layer over the top as an easy way to for customers to transition? You could use the existing service as a test suite to check your compatibility API behaves the same as the original product.

> There's no way Cloudflare could have pulled this off without next's very own tests.

I'm very uncovinced. History showed us very complex systems reverse engineered without access to the source code. With access to the source code, coupled with the rapid iteration of AI, I don't see any real moat here; at best a slight delay.

Source code is one thing; tests covering the codebase are another.

And if you just copy the source code or translate it one-to-one into a new language, rather than make a behavioral copy, there will be copyright issues.

> there will be copyright issues

Next.js is MIT-licensed. Cloudflare's rewrite is... also MIT licensed...

Of course. I'm referring to rewrites of other software; you can easily launder GPLed code this way, for example.

The tests are absolutely essential, otherwise there's no signal to guide the LLM towards correct behavior and hallucinations accumulate until any hope of forward progress collapses.

Obviously the signal is comparison against the behavior of the original.

I have tried to post this here but it has not got traction.

I have a demonstrated process here on my blog (all hand written without AI).

This bit about how to brute force decompilation: https://reorchestrate.com/posts/your-binary-is-no-longer-saf...

And this about how to do the conversion and address the LLM hallucination problem: https://reorchestrate.com/posts/your-binary-is-no-longer-saf...

Yes, it is absolutely possible.

There was a recent post on here where the creator of Ladybird (Andreas Kling) translated a chunk of his novel browser from c++ to Rust in two weeks -- a feat he estimated would take him months: https://ladybird.org/posts/adopting-rust/

I, in my own way, have discovered that recent versions of Claude are extremely (as in, super-humanly) good at rewriting or porting. Apparently if recently released coding agents have a predefined target and a good test suite then you can basically tell them that you want X (well-defined target w/ good suite of tests) written in Y (the language/framework you want X written in but it isn't) -- and a week or two later you have a working version.

I have spent the last month wrapping my head around the idea that there is a class of tasks in software engineering that is now solved for not very much money at all. More or less every single aspirational idea I have ever had over the last 20 years or so I have begun emabarking on within the last two months.

I hear you.

I am curious, have you attempted to do this to any binary packed with commercial obfuscation/"virtualization" schemes (e.g. Orean's Themida/Code Virtualizer and VMProtect)?

No, I would need to find a binary to test on. I suspect it would produce horrible code at the decompiler layer but ultimately I would expect that function signatures are still relatively clean?

Its scary - once you get the differential testing harness set up it seems to be just a matter of time/tokens for it to stubbornly work through it.

> I wouldn't be surprised if we end up seeing open source commercial work bend towards the SQLite model (open core, private tests).

Wouldn't this just mean that actual open source is the tests? or spec? or ... The artifact which acts as seed for the program, what ever that ends up being?

The point is that artifact is not open.

I'm not sure about this. LLMs can extract both documentation and tests from bare source code. That said I think you're correct that having an existing quality test suite to run against is a huge help.