The barriers to open source healthcare we need to solve

This episode of Out-Of-Pocket is brought to you by…

Deerfield strives to collaborate with visionaries at every stage, including founders, researchers, and teams across healthcare (including Nikhil & Out-of-Pocket - you might remember our AI B2B hackathon!) But we’re not just investors - we’re operators who aim to bring R&D capabilities, operational guidance, and an expansive network to bear as healthcare companies tackle complex challenges. 

‍See how.

—

‍Wanna chat sponsorship? We have a handful of opportunities coming up, let’s chat

Open Source Is Breaking

If you need to get up to speed, in part 1 we talked about how open source software is having a moment in healthcare. In part 2 we talked about the specific areas I think will take off.

Part 3 is where I kill the optimism that made you feel something for a second.

When open source software was limited to just engineers, it was already fraying a bit but it was manageable. When everyone is able to access open source software, a lot of the systems in place are not going to work and we have new issues. 

I like to argue with myself, so here are some risks and barriers to open source adoption. I think calling the risks out means we can better fix and address them, so I also have some proposed solutions.

This is not an exhaustive list of all issues, just some that come to mind most immediately

Security On Personal Devices

One of the reasons people are flocking to open source tools is to get around the restrictions from existing operating systems they use. Apple doesn’t want me to do this, Anthropic puts up guardrails, Epic says I can’t do X. Now I can run some LLMs or bots using open source software on my computer and get around it! I am computer god. 

Except that a lot of those guardrails are put up for legitimate security reasons. OpenClaw is a good example of this - it lets you run an autonomous AI assistant on your own hardware but requires access to your email, calendar, files, and the internet to be most effective. 

What makes it awesome is also makes it vulnerable from a security perspective. It becomes easy to prompt inject your AI and get it to do things it shouldn’t since it has all your credentials. It’s why big companies are banning it and why your only “crypto → AI” friend is about to lose a lot of money by accident. With healthcare data in the mix, the stakes feel much higher.

It does seem like there’s an opportunity to build:

1) A micro managed services company to help people set this up more securely. Come to my house, securely set up my agents, be my friend, what’re you up to this weekend, oh actually I’m busy too.

2) Set up the modern Norton antivirus, except it’s for monitoring your computer/agents and what they’re doing from an exposure perspective. 

3) Something that allows enterprises to create vetted lists of open source projects their employees can use that don’t go through a full enterprise procurement.

{{interlude 3}}

Back to your regular programming…

Maintenance, upkeep, and validation 

One of the reasons people use vendors even when open source exists is because maintenance and upkeep of homegrown software sucks. Today it’s still a huge pain in the ass to maintain internal projects on top of open source once it hits a level of complexity. You also own the liability if things go wrong - who’s supposed to validate which open source software is good to use? It’d be nice to blame someone else, like a vendor! Or Obama!

There’s also the risk that a project you depend on just… stops being supported. The development team moves on, the company changes its mind, and suddenly you’re on your own. Now you gotta be responsible for this open source software.

Healthcare just went through this. Mirth Connect is probably the most widely used healthcare integration engine out there. It translates HL7 messages between systems and basically keeps data flowing between hospitals and health information exchanges. It was open source for nearly two decades, but was then acquired by NextGen and they announced it would move to a fully commercial, proprietary license. You could use the old version that’s still open source, but then maintenance is on you.

The question is what maintenance looks like as software engineering AI gets better, and what software you can homegrow vs. you’d want to outsource. 

Governance - who should make decisions?

Most open source projects in healthcare have basically zero formal governance. Someone builds something cool, puts it on GitHub, and the “governance” is just… some dude answering GitHub issues when they feel like it. This is fine when it’s a side project but dunno if that’s going to fly for healthcare enterprises.

The broader open source world has a few governance models. 

• “Benevolent Dictator for Life” (BDFL) model where one person calls the shots. Linus Torvalds with Linux is the quintessential example of this. The pros is that one person has a cohesive vision for the whole software, but the downside is when the one person needs to do anything else with their life lol.
• There’s foundation-backed governance. This is where a nonprofit manages trademarks and legal while technical decisions get delegated to committees. 

• And there’s the “do-ocracy” where whoever does the most work has the most say. Is it a meritocracy? Or just whoever has the most free time?

Each one of these styles has different tradeoffs associated, so there’s no “right” answer. But there’s a few key questions that need to be answered.

Who decides what goes into the next release - For healthcare open source, you probably want clinical end-users in that process, not just engineers. You also probably want a paper trail of how decisions came to be, even if it’s a forum post where people are fighting over inane nonsense.

Succession planning - What happens when a key person (e.g. solo maintainer) gets a big job at Google and loses interest? Healthcare projects need a plan for leadership transitions. 

Legal clarity on direction - Who actually “owns” an open source project? The copyright holder? The foundation? The community?You want to know who’s accountable if the open source EHR you deployed suddenly takes a hard left turn architecturally.

The HL7/FHIR model is actually interesting as a template here. It’s an open standard with open source reference implementations, but you pay a membership fee to participate in governance over how changes get made. Enterprises pay which keeps the foundation sustainable while also getting some say in governance which makes them more likely to feel comfortable with adopting it.

The "one person in Nebraska" problem 

A shocking amount of critical infrastructure depends on open source projects maintained by a tiny number of developers. A lot of those developers are doing this for free, and still people are constantly telling them to improve the software or approve their changes. Entitlement knows no bounds.

Those small groups of people might be responsible for making sure those changes are not security issues. Since the software is free, it’s used by A LOT of people which means malicious software can hit a bunch of people quickly. You might have heard of Heartbleed, the name alone will send CISOs running to the bathroom. A key piece of security infrastructure was maintained by two developers both named Steve (not a joke) on a budget of about $2,000 a year in donations. 

Don’t think healthcare open source projects can let that happen. There’s going to be more demands around the financial stability and security of projects before they’re adopted. I’m not sure there’s a specific fix here, but will probably resolve itself if the business model issues are fixed. 

Corporate freeloaders 

A lot of big companies are happy to use open source tools but don't contribute engineering time, funding, or even bug reports back to the projects they depend on. They’ll save millions using an open source software and put zero resources toward maintaining the thing they depend on. This is a problem across all of tech but it's especially acute in healthcare where the companies benefiting the most (large health systems, payers, etc.) have the deepest pockets and the least ability to contribute because they're not engineering-culture organizations.

Honestly, I think the fix is a new open-source license. The classic licenses like MIT and Apache basically let you do whatever you want, but they were designed in a different time where software engineering was a much smaller and more niche field. We need something that lets people tinker quickly but makes it more difficult to make money without contributing back. There are already some examples that specifically try to punish company freeloaders:

• Business Source License (BSL) was created by the MariaDB founders (MySQL people). The code is available for everyone to SEE and use it for tinkering or testing. But if you want to use it in production you need a commercial license that’s paid. The interesting part is that after a set period (usually 2-4 years), the code automatically converts to a full open source license like Apache 2.0. This essentially creates a  “delayed open source”, which actually doesn’t look too different than how pharma patents work!
• Server Side Public License (SSPL) from MongoDB. It says: if you offer this software as a service, you have to open source all of the service stack under the same terms. Basically you can freeload, but then you have to share everything too. Obviously corporations would not be down with that, but maybe if software truly is becoming a commodity then they won’t care.
• Llama 3 - Meta has a Community License Agreement with Llama 3. This basically allows you to use, modify, and redistribute the model + weights. But you have to include attribution to the model, it restricts specific use cases like weapons/surveillance, and if you have 700M MAUs then you need a separate paid commercial license from them. 

For healthcare specifically, I think there’s room for something even more targeted. Imagine a license that says: free for healthcare delivery organizations under a certain size, free for researchers and nonprofits. But above a certain number of beds, users or revenue then you have to contribute back in the form of engineering hours, funding, or validation data from the real-world.

True open source people are not going to like this suggestion, they call it fauxpen source and cyberbully people about it. But the future is now old man, get with the times.

Managing bad open source contributions 

While I do think more people being able to contribute to open source will be a good thing, the ease of contributing is also flooding open source projects with pointless additions so people can claim credit for helping maintain a project. The signal value of a contribution is going down as the cost of producing one approaches zero. I think this means we’re going to need better systems that actually rank how valuable someone is to a given open source ecosystem.

This problem extends to open datasets too. A huge area to solve in open datasets is figuring out who’s allowed to add or correct data to these open source datasets. Right now basically only the people involved with the companies or institutions that release this data can do that, but IMO there’s a lot of value in allowing people to contribute their own validated data to these datasets

We’re probably going to need better systems that actually rank how valuable someone is to a given open source ecosystem. This is where AI as a judge will become useful since it can look beyond the count of commits and actually weight them by impact, complexity, and whether the maintainers actually wanted it. Then we can have contributor rankings and badges that give you more permissions to do things across projects. A similar reputation system could be implemented for people that want to contribute datasets, which get validated by peers of some sort until you reach a reputation score that requires less peer review.

A few featured healthcare jobs

Some cool companies are hiring!

Duet Health - ​Director, Value Based Care​ (Hybrid, NYC)

• The Director, Value-Based Care will oversee Duet’s Medicare ACO programs and value-based contract performance across our growing national network of NP-owned practices. This role sits at the intersection of population health strategy, payer performance, clinical transformation, and data-driven execution. This is an exceptional opportunity to help build Duet’s value-based care engine as we scale nationally. ​Apply here.​

Parakeet Health - ​Customer Success Manager​ (SF, In-Person)

• Healthcare still runs on hold music and fax machines. Our AI agents handle calls, faxes, and patient outreach for practices across all 50 states -- automating the most tedious admin tasks. We're hiring CSM #2 to help practices transition to this agentic world. Lean, ambitious, and AI-pilled team. ​Apply Here​.

Pairtu - ​Head of Ops/ COO​ (SF, Remote)

• Pairtu gives Medicare patients a dedicated advocate to navigate billing, insurance, follow-ups & more. Serial entrepreneurs, mission driven co that started after mother got cancer and uncle passed to chronic conditions. Backed by top VCs and live in all states. Come run the company and 10x it ;) ​Apply here.
  

Open data enables vigilante analysis

IMO open data is good. However, healthcare data is particularly complex and requires understanding the context of the dataset before drawing conclusions. People are screaming for heads on spikes, calling for vigilantism like showing up to places with anomalous billing, and slicing data in specific ways to further whatever narrative gets clicks in your echo chamber. This is especially true when non-data literate folks just dump it into Claude and ask it to “analyze it, make no mistakes”. 

The open source DOGE Medicaid dataset is an example. It’s genuinely an interesting dataset, but suddenly everyone was a Medicaid billing expert. People on social media were pointing at statistical outliers and screaming "fraud!" without understanding the clinical context (e.g. many providers will bill through intermediaries). The dataset started a discussion and lots of people came out to correct the analyses too, which is the power of opening them. But someone is going to get hurt because of a data misunderstanding.

The Vaccine Adverse Event Reporting System (VAERS) is another example of this. We talked about how open source databases struggle with governance and who can add to it. Anyone can submit a report about an issue they faced post-vaccine to VAERS, it’s an intentionally low friction process that doesn’t require verification. A doctor submitted to VAERS that he turned into the Hulk to prove that point, and it was accepted into VAERS. As you can imagine, a lot of anti-vax communities will cherry pick data from VAERS (e.g. show absolute numbers instead of %) to show a point about vaccine safety.

One fix might be controlled sandboxes with the data. For example, the All of Us Researcher Workbench model lets you peruse the data from the biobank, but you have to do it in a controlled sandbox environment and complete training on responsible data use first. Maybe you should have to take a custom text to make sure you understand the data before you get access to it.

On the net I think transparent data is really helpful, but when it collides with social media weird things happen.

Conclusion and parting thoughts

It’s been interesting asking people “are you more or less bullish on open source software” when I encounter anyone that seems like an engineer. The responses are extremely polarizing, ranging from “it’s officially dead” to “it’s never been a better time” to “wait are you the guy from Microservices video?”

One thing I know is when the opinions are polarizing, there’s usually something big to be built there. Let’s see if I’m right!

Thinkboi out,

Nikhil aka. “Mopin’ source” aka. “Just marry open source if you like it so much jesus”

‍Thanks to Colin Durant, Uzair Khan, and Juhan Sonin for reading drafts of this

Twitter: ​@nikillinit​

IG: ​@outofpockethealth​

Other posts: ​outofpocket.health/posts​

‎If you’re enjoying the newsletter, do me a solid and shoot this over to a friend or healthcare slack channel and tell them to sign up. The line between unemployment and founder of a startup is traction and whether your parents believe you have a job.