I make a good living as an open source software engineer in biotech.
I repeat, I. Make. A. Good. Living.
This often comes as an awkward surprise when I introduce myself at parties until some kind soul who knows what I do helps explain that I'm not some weird evangelist "free" software dork working for pennies. I forged this career path with clear intentions and a strategy that eventually worked.
There's a lot of magical thinking surrounding the business of open source software. A lot of investors squirm at the idea of their portfolio companies' IP being "stolen". Many engineers think that
users == money. Truth is these two groups are thinking about the business of open source stuff (and closed source stuff) all wrong. Not everything should be open source, but there are some things that should always be open source.
To better explain let me tell you the story of how I came to this conclusion.
When I started the open source project that would and still does define my career I was really burned out on biotech. To be frank, most biotech software didn't and still doesn't work, and I was and still am sick of it. At the beginning of the pandemic I was getting ready to leave the field entirely until my friend Keoni called me while he was driving down the California coast and said to me:
"I can't find a way to reliably convert JSON to Genbank and back" - Keoni
JSON is the world's most common data format. Almost every programming language written in the last 20 years has native support for it. Genbank is the world's most common data format for annotated genomic data. It was created by a secret council of jerks in the deserts of New Mexico sometime around 1978. It's ridiculously hard to parse and most languages don't have any support for it.
Here's the world's most common data format and the world's most common genome format and my friend can't reliably convert between the two.
So I look into it more, and it turns out he's right. The field of biotech is so technologically bankrupt that despite the plethora of "platform", and "techbio" companies, labs, and non-profits there's not a single reliable, off the shelf solution for reading and writing Genbank into JSON and back. I sighed, and said to him, "Eff it. I'll write a parser. Give me a week".
It took me three.
The crazy thing about that parser? It worked. Better than any conversion tool available then or now. I spent weeks chasing broken links on government websites with expired certificates for any sort of documentation on this blasted format before I was able to cobble together a working prototype that has been rewritten many times over since. I told Keoni I didn't consider it production ready and tried to forget about it.
Within the week Keoni was using it in production and to this day all Genbank files shipped by Freegenes have this line in it:
Created using Poly
Revelations: I'm the best?
"How tf are people doing synthetic biology if they can't even parse the files they need?" - me
It dawned on me that inside every synthetic biology "platform" company one of two things must be happening tech wise:
- They're lying through their teeth and have absolutely no "platform" to speak of.
- They're burning millions of dollars of investor cash writing basic stuff in house or through contractors that give them almost zero advantage against their competitors who are also doing the same thing.
Ignoring the first case which is investor fraud let's talk about how I found "product market fit" with the second case.
"Product Market Fit"
Like most professionals, VCs have invented a bunch of their own inane jargon that you have to learn when dealing with them and like most professionals they use this jargon to sound smarter than they actually are at the expense of their clients who have no idea what they're talking about. "Product market fit", is one of those terms.
In VC speak when you've, "found product market fit", it means you've, "found people who will pay you for your product" i.e customers. Those companies burning millions of dollars of investor cash writing basic stuff in house? That's the market my open source product fits.
My product is the best-in-class software solution for engineering organisms and unlike my closed source competitors I can easily prove it by just showing customers the source code. My marketing and development overhead costs are minimal thanks to my users and contributors, and adopting my software can save a company millions in initial software development and continued maintenance costs. The biggest pain in the butt for me is the biggest pain in the butt for almost every other business on Earth. Sales. F*ing sales.
Like Love, Selling Hurts
Selling your product can destroy you emotionally if you're not prepared for it. After I wrote that parser for Keoni we kept writing more and more stuff that we needed and everything kind of snowballed. There was obviously a desperate need for higher quality software in the field and more and more contributors were throwing code and ideas at us but there was a small problem. None of them were throwing money.
If you're thinking about building a company that sells products to other companies, open source or not, listen very carefully to what I'm about to say. Your users are not your customers and vice versa, and you should never, ever, confuse the two.
Both are vital. Your users drive adoption, advocate for you to their employers who can pay you, help you refine your product, and generally make everything more fun. Your customers (sometimes your users' employers) write checks and keep the lights on but they'll likely never personally touch your software.
A lot of business to business (b2b) companies seem to be only good at building for their users, or selling to their customers but it's extremely rare that they're good at both. To stay in business you usually have to adequately do both.
So, I had a product that users were using but like many software products I didn't have customers who were paying. The important thing to realize is that those two things do not have a causal link. There are inferior software products with fewer users than mine that generate far more revenue and there are software products with way more users than mine that generate the same amount of revenue.
Trying to sell this thing hurt. A lot. Constant meetings with random startups, corporations, academics, VCs, etc. Zoom fatigue is real and that much ambiguity and rejection can destroy your ego if you're not ready for it.
When I first started I didn't even know how to sell to customers. I was trying to sell to them the same way I convince users to use my software. It wasn't until I expressed my software's value in dollar figures that customers started to pay attention.
My Sales Advice is Probably Bad but it's Better than Nothing
If you're an engineer like me then I have to break some bad news to you. You probably really suck at sales. All your professional contacts are engineers who don't control their companies' purse strings and instead of learning how to throw ragers, do keg stands, and have a good time like every salesperson did in college you spent your time learning math. Even mathematicians will tell you that math doesn't pay.
There's probably a jargony term for the phenomena I'm about to explain but since I don't know the proper term I'll call it the naive buyers problem.
Often your customers will have no idea what you actually do. Their conviction to buy comes from pure faith and social proof because for most part they're not qualified to evaluate whether you can do the job or not. That's the whole reason why they're hiring you. You're supposed to know how to do something they don't understand or know how to do.
My go to example for this is the small business my dad started when I was a child. My dad is a real estate attorney and he's the best at his niche. He takes on plenty of specialist work but his bread and butter are real estate closings. When two parties close a real estate deal my dad is the one who confirms that the seller really owns the property for sale and that the buyer can really buy the property for sale and then presides over the sale to ensure that everything is squared away legally.
My dad is the best at what he does but the real estate agents who refer him to clients and bring him these closings for the most part aren't capable of knowing that. They're not lawyers. They can only tell if he makes a mistake. They don't understand the level of expertise he has that allows him to not make mistakes.
So how did my dad differentiate himself from other real estate attorneys that provide the same service? He doesn't make mistakes and serves the real estate agents who refer him to their clients lobster, beer, and steak at his business partner's lake house every summer. Real estate agents don't know exactly what he does but they will happily recommend him to their peers and clients because he doesn't make mistakes, is timely, and can throw a nice party.
You probably suck at keg stands but from this example you may start to see how it may not matter if your product is open source or not because your customers simply don't care either way.
What Things Should Always Be Open Source?
I'm convinced that a lot open source platforms will eventually steamroll their closed source competitors. I'm not going to into full detail on how or why cause that's another topic for another time but here are the basics on deciding whether something should be open source or not.
Open source absolutely every piece of software you can that isn't your company's secret sauce, or some embarrassingly bad production code.
Parser for some obscure file format? Open source it. Golden Gate cloning simulation function that can be isolated from the product it was developed for? Open source it. Your drug discovery pipeline for a specific target? Probably want to keep that to yourself because only your direct competitors would care about that.
The first thing a lot of software engineers do when prepping for a job interview is to look at their prospective employer's public Github Profile. If you're having a hard time hiring developers; find your most interesting, highest quality, non-secret sauce piece of software then clean it up and open source it under an MIT license immediately.
I Hope This All Makes Sense
Poly is a carefully designed product for a specific market that I could never compete in if it weren't open source.
It's my calling card, my social proof, my credentials, my advertising, and the technical basis for all of my other projects. Its superior quality establishes me as the leading expert in a field full of technologically bankrupt thought leaders with fancier credentials. Its community of users is the social proof my customers need to know that I'm the real deal. If my work wasn't open source I wouldn't be able to make it in my field, period.
If you're considering making a living as an open source developer just understand that you're making a living as the owner of a small business. It could take years for you to turn a profit and if you build it no one will come unless you market and sell it. You have to be diligent and provide the best product, at the best price, with good profit margins, and know your market. Honest to goodness after launch you'll be lucky to get a good day or two of engineering in a week. The rest will be sales, marketing, and back office stuff that I personally loathe.
Thankfully, a nice company did the math and realized my work will save them millions so they hired me to work on Poly full time and freed me from the tedium of marketing, sales, and administration that comes with being a small business owner. Of course I still take contracts and consult on the side but now I can be choosy.
Open Source is Sustainable, Your Business Probably Isn't
It's far easier for an investor or ex-CEO to say that open source isn't sustainable than it is for them to admit that they created a lemon whose core product just happened to be open source.
RedHat, GitLab, and MongoDB are all public companies whose core products are open source. Every website you've ever used is built on top of an absurd amount of open source software libraries. There's a market here and if someone is not able to see it that says more about them than it does about the sustainability of open source software ¯\_(ツ)_/¯