How AI and Open Source Shape the Future After Job Loss

Robert Jacobi: Welcome to Open Channels News. I’m your host, Robert Jacobi. Today, laid-off engineers are using AI to build open-source alternatives to subscription software. An experimental Linux display driver has gone offline after a patent complaint. And a new report looks at how much access developers, bots, and AI agents have to the code their companies depend on.

First up, Cybernews reports on OccupySaaS, a collective of laid-off engineers that wants to give businesses open-source alternatives to familiar subscription products. Its first 2 releases are ZeroAuthy, aimed at the identity service Auth0, and SalesCompel, aimed at Salesforce. Both are early versions. The interesting part right now is how the group says it builds them. The collective describes a clean room approach. It says it works from public documentation and open standards, keeping former employees’ confidential information out of the process, and tests compatibility against the vendor’s public developer tools. Humans write the specifications and review the changes. AI helps turn those specifications into code.

Picture a small company that wants to move away from a hosted identity service. The login screen is the piece everybody sees. Behind it are the apps that depend on it, the rules about who can sign in, the password resets, and the integrations that have to keep working on Monday morning. An early release gives the company something concrete to try. Whether it can move depends on how well the alternative handles those details and who can help when a migration hits a snag. That’s where I’d look for the real competitive pressure. If a small team can build a credible alternative faster, customers get another option. For that option to last, somebody has to answer support questions, ship security updates, and keep compatibility from slipping. Those costs belong in the same conversation as the subscription bill.

Now, from replacing a software service to getting a piece of hardware to work on Linux. Phoronix reports that VINO, an experimental open-source driver for newer DisplayLink hardware, is no longer publicly available. DisplayLink is the technology you may have in a USB dock that connects your laptop to external monitors. VINO was written in Rust, developed partly with AI, and described as a clean room reverse engineering effort. According to Phoronix, the developer received a cease and desist notice from Synaptics over alleged patent infringement. The reporting points to correspondence shared on a Linux kernel mailing list. The allegation is Synaptics’ position. What users can see for themselves is that the public VINO repository is gone.

There’s a distinction here worth slowing down for. Writing your own implementation tells people something about where the code came from. The complaint in this case was about patents. The 2 OccupySaaS projects and the VINO driver all illustrate how much easier it may be to get an independent implementation started. What happens after that depends on the product, the rights at issue, and whether the people doing the work can keep it available. If you’re the person who just wants the dock on your desk to work, that can feel pretty far removed from the problem you’re trying to solve. But public development is how other people can test a driver against their hardware, report where it fails, and help maintain it as Linux changes. When the repository disappears, so does that place to work together.

Finally, Help Net Security reports on BlueFlag Security’s study of developer access. Among the repository tokens BlueFlag measured, 99% had no expiration date. 84% allowed code changes. Nearly half had gone unused for more than 90 days and still hadn’t been revoked. Those figures describe what BlueFlag measured, and they give us a concrete way to think about a permission that can outlast the work it was created for.

A token is a credential a tool can use to access a system. Say you give a coding agent access to one project so it can prepare a change. The job ends, everybody moves on, and the credential is still active. If that credential can write to a repository, its owner may be able to change code long after anyone remembers why it was issued. If it can read other repositories, the exposure reaches beyond the job you gave it.

BlueFlag also found unapproved agents in 83% of the organizations it measured. Some coding tools act through a developer’s account, so the activity can look like it came from a person. Others have identities of their own. Either way, when an unexpected change shows up, somebody needs to be able to trace it back to the tool or person that made it. Here’s the question I’d be asking if I was reviewing one of those deployments. When the job ends, what tells the system to take the access away? An expiration date helps with the forgotten credential. Narrow permissions help while it’s active, and a record of which tool did what gives the next person a place to start if something goes wrong.

Across all 3 stories, getting software to do something is the start of the work. The identity service still needs support when someone can’t log in. The driver still needs a place where people can fix it. And the coding agent still needs a way to hand back the keys when it’s done.

That’s it for today’s Open Channels News. I’m Robert Jacobi. Be open and stay secure.