I was in the office with the team when we heard that Google had released Artemis, a project for automating mobile devices. We opened the repository and started looking through it. My reaction was pretty immediate:
“What the fuck? We wrote this.”
We built mobile-use as an open-source research experiment to see whether we could get AI agents to reliably interact with phones. We worked on that through February, then focused on a newer, more powerful, closed-source version that now powers QA across web and mobile at Minitap.
Finding familiar code in another project is something you expect when you publish your work for people to use. Finding it under Google’s name, without an acknowledgment of where it came from, is harder to take.
Then we looked at the history and found our names in an older version. They had been removed.
I’m disappointed in Google. And I think this matters beyond our own repository, because open source depends on people being willing to keep sharing their work. The way that work is treated matters.
What we recognised #
The examples were specific. Parts of the code for connecting to Android devices matched our implementation exactly. The Hopper agent’s instructions were identical, word for word. Those matches were still present in the Artemis version we checked on September 11: here is the Artemis device code alongside ours, and the Artemis prompt alongside ours.
Fun fact about Hopper: we didn’t know what to call that agent. Jean-Pierre, one of our engineers, likes Minecraft and thought the name was cool, so we went with it. That was the reasoning. Seeing the same name attached to the same instructions in Google’s repo felt very familiar.
An example for keeping an agent inside WhatsApp had the same task of sending Happy New Year messages to Alice, Bob, and Charlie, with the same comments and cleanup steps. That was still there too. Compare the Artemis messaging example with the mobile-use example.
Older versions even shared a bug: a helper would write a results file, then fail when it tried to read its own output on the next run. We reproduced the same failure in both implementations. Artemis has since fixed it.
The author history was harder to understand. An earlier package file listed Pierre-Louis Favreau, Jean-Pierre Lo, and Nicolas Dehandschoewercker. The version that replaced it removed all three names and substituted another author. The only change to the files was the author list. GitHub’s activity record shows that the replacement happened through a force push in August, before our investigation this September.
Our names in the earlier Artemis package file. GitHub now marks this version as detached; its activity record shows it was previously on the main branch. File.
The author list after the replacement. Source.
Artemis contains its own engineering work too. It can acknowledge that work and the mobile-use code it incorporates in the same place. Yet the README we checked did not credit mobile-use. We have put the detailed comparisons, the archived files, and the timeline in a public factual record.
Sharing code should make collaboration easier #
We chose open source because we want other people to build on mobile-use. Someone should be able to take it in a direction we would never have considered. They should be able to improve it, turn it into a product, or build a competing project, within the license’s terms.
There are ordinary ways to do that while keeping its origins clear. A fork links back to the original project. An imported copy can document its source. Copyright and attribution notices can stay with the code. A README can explain which parts came from elsewhere and what the new team has added.
Some of this is established engineering practice. Some is required by the license. The mobile-use source used for the current comparisons carries Apache 2.0, whose redistribution conditions include preserving applicable copyright and attribution notices and identifying changes. It also provides for retaining relevant attribution from an upstream NOTICE file when that file is included in the distribution. Apache 2.0, section 4
That information is useful to everyone who comes next. It helps people find the original maintainers, understand a design decision, report a bug, or share a fix. It gives contributors a record of what they built. It lets a new project explain its own contribution honestly.
I should not need to recover an old version of a repository to discover that relationship. Maintainers already spend time answering questions, reviewing contributions, and keeping their projects working. Chasing missing attribution after a larger company republishes their work is another cost of sharing. An ecosystem that makes this routine gives people another reason to stop doing it.
I want more people publishing useful software, with more confidence that their work will still be recognised when it travels.
Our benchmark results have also been hard to get heard #
We had already spent months asking for our newer results to be reflected on AndroidWorld’s leaderboard.
The maintainer applied our earlier submissions, up to 91.4%, with the last confirmation in December 2025. We then submitted 94.8%, followed by 100% in our evaluation in January. We sent two follow-ups. Those four emails received no reply. Our results and task traces are available for inspection.
As of September 11, the sheet still showed mobile-use at 91.4%, while Artemis appeared at 99.1%. These are self-reported results; the leaderboard explicitly says it does not independently verify them. That qualification applies to our reported 100% too.
Artemis’s own comparison chart omitted us. It included DroidRun at the same listed score as mobile-use, and an unrelated MadeAgents project called MobileUse at a lower score.
This is Artemis’s own chart. The “MobileUse” near the bottom is a different project. Source.
We have no evidence connecting the unanswered emails or the chart omission to the removal of our names. But this is another part of our experience of trying to get the public record to reflect our work. We would like a response to those submissions and an explanation of the comparison.
We’ve contacted Google #
We’ve already contacted the Google team. There is also a public issue on the Artemis repository. We’ve asked them to acknowledge that Artemis is derived in part from mobile-use, credit the people behind it, and put the attribution right. I’ll update this post when we have something substantive to share.
What disappoints me #
I’m disappointed in Google. This is the company that gave us Kubernetes and TensorFlow. When it launched Chrome, it explicitly credited WebKit and Firefox, writing: “We owe a great debt to many open source projects.” Google has a history of doing this well, and published guidance for handling other people’s code. That is exactly why I expected better. The original Chrome announcement.
I’m disappointed for my team. They did an insane job on mobile-use. Through December, January, and February, they were focused on making this work. I saw the effort that went into it. These are their implementations, their examples, their weird Minecraft-inspired agent names. I want them to see that work used and feel proud of it. Having to dig through somebody else’s repository to establish that they wrote it is a pretty shitty outcome.
I’m disappointed for the open-source community. It deserves better treatment than this. People put their work out there so others can learn from it and build on it. The people and projects behind that work deserve to remain visible. If even a release from Google means maintainers have to chase their own attribution, we are making it harder for people to feel good about sharing. That is not the kind of open source I want to be part of.
On the bright side, the version powering Minitap today is closed source. And it’s a completely different beast by now. Google, you’re seven months late. Next time, just ask for a demo.