placeholder

/dev/lawyer

>> Law, technology, and the space between

All content by Kyle E. Mitchell, who is not your attorney.

You can subscribe via RSS/Atom.

Bilking Angelscelestial finance for earth-bound developers

This is the second in a series, Killjoy, in which I sketch unorthodox and unwelcome solutions to nagging open source problems.


There’s a lot of concern these days about financial support for open source software. Who will pay for accomplished developers to make software that nobody pays for?

For the last few years, there’s actually been a fairly common answer: angel investors.

WARNING: Running the following plan dishonestly is fraud. Calling that out is part of the point here. Do not commit fraud.

Step-by-step:

  1. Hock your open-source project as a start-up business. Don’t fret revenue. Emphasize the chance you’ll be acquired for nebulous, strategic reasons, for cash and public-company stock.

  2. Raise as much money as you can on founder-friendly terms with no meaningful financial or company-control consequences. In other words, on SAFEs.

  3. Use the money to pay salaries and benefits for yourself and your open source friends. Stretch it out.

  4. Amass reputation and experience in public work. If you like, allocate a marketing budget for telling the world how great you are.

  5. Release everything under the permissive open source terms you would want for the project.

  6. If you’re not acquired for gobs, and money runs out, shut the company down and move on. Keep your reputation, experience, and even your code, which your former company now licenses to you or your new employer on the terms you yourself picked.

If you’ve managed to run this plan accidentally, setting out from the get-go to make 10× and conquer the known business universe, but ending up insolvent or “merely” self-sufficient, congratulations. You are not alone. Keep trying.

If you’ve managed to run this plan negligently or cynically, you’re the problem. Enjoy this blog post.

If you’ve managed to fund this plan, I’d ask you to think on what you can do to avoid doing so again. I love open software, and spend nearly every day working to get its producers paid … for the right reasons. Money for the wrong reasons, or no reason, doesn’t help. Success is a good outcome and a generalizable solution to the very general open source funding problem, not any check in the bank, by any means. Success is when angels funding open source is good for angels, too, and keeps them coming.

Hail, SAFE!

In ye olden days, early-stage startup companies raised money using agreements called convertible notes. These were essentially small-business loans that defined success in terms of raising money from more demanding venture capitalists, instead of near-term profit.

If the debtor-company managed to raise money from VCs, the amount invested on the note would transform into the same kind of preferred stock the VCs bought in the financing, rather than cash. Hence convertible. Conversely, if the company stayed in business for a number of years, but never raised VC, the notes came due like a loan, with interest. Hence note. In a nutshell, the convertible note bound the company either to raise venture capital or to make enough money on its own to pay the investor off.

The SAFE, promulgated by Y Combinator, the leading startup accelerator program, changed that norm. Riding promises to be neither voting stock nor equity, the SAFE swept the land as the easy, standardized, early-money investment vehicle of choice.

More critically, SAFEs reflected high startup leverage, and boil down to founder-friendly convertible notes. Most notably, if a company doesn’t raise venture capital or achieve an “exit”, it doesn’t owe SAFE investors anything until it folds, at which point there’s usually no money to pay out, anyway. SAFE money invested becomes, essentially, a free financial boost. There’s no effective commitment to the VC-backed startup path. The company can take an off-ramp to the relatively lower-speed, small-business route.

Plenty of companies set out on the startup superhighway, and find themselves holding down a more traditional small-business line, making money but not crazy money, or simply running out of cash. Some of those companies make open source professionally, which costs, but doesn’t pay. Cost without pay is a privilege above the financial rank of a startup, afforded by a shot of outside capital. Capital invests in the business, which invests in time and talent to make code.

Escape Hatch

Founding, funding, and failing a Silicon-Valley-style startup is in many ways its own reward. There is a certain tolerance and even celebration of failure among entrepreneur-types. But this was about open source.

The day-to-day trouble with a no-real-strings-attached open source startup is much the same as with paid open source work. Working in the open, on open source, creates all kinds of positive externalities for the individuals involved. Externalities the company itself, if it’s small, and especially if it’s controlled by the open source developers, can’t or won’t attempt to capture.

In this day and age, development tends to happen via personal accounts, on GitHub and even on distribution systems, like npm. Conversations spill out onto IRC, Twitter, and other channels. Personal identity is primary. Corporate affiliation is secondary, and often temporary.

But of course it needn’t stop there. Marketing expenditures raise the profile not only of the company and its product, but those contributing in their own names. Conference and trade show attendance yields name recognition and networking. Some of these benefits are standard to in-house coders, as well. But the overall package is rich.

There are offsetting problems. Dealing with a user community, without HR support or work professionalism standards, through gamified social media platforms across time zones, works developers over pretty hard. Not many last more than a few years. But that’s about par for startup gigs, too. Compared to an independent contractor agreement for open source development, company taking SAFE investment affords greater financial discretion, a more autonomous working relationship, and far greater control.

The coup is the code. In a traditional startup, all the intellectual property from founders, employees, and contractors goes into one big hat called the company. Founders and funders buy shares in the hat, interests in the business opportunity it creates. If the company fails, everything in the hat goes onto the auction block, proceeds to compensate investors first, to offset their loss.

With open source, especially permissive open source under licenses like MIT, BSD, and Apache, the hat has a hole in the bottom. Code falls out. There’s no value in owning code that anyone can use for free for any purpose, without any meaningful conditions.

Corporations frequently develop software under such permissive open-source terms as loss-leaders, or release software they’ve already developed under such terms, in hopes of defraying further costs. But with no financial accountability, founders can make every decision to maximize adoption of their software, maximizing their personal benefits as they do. They can nurse the delusion that blockbuster adoption success, at a price of zero dollars, will inevitably breed dollar-making opportunity, and that their company will be best positioned to seize that opportunity.

It doesn’t work like that. If it doesn’t work long enough, the company will fold. But when the company folds, any number of developers—at other companies, at competitor companies, the departed startup founders themselves—receive the public open source license the company granted while it lived. It can be very difficult to revoke those licenses, legally and practically. Often, the liquidation potential just isn’t worth it, and rights in the code end up legally orphaned, without any clear owner. Nobody really knows who owns the code. But it doesn’t matter, since the open source license gives all their exclusive rights in the code away to everybody else, and licenses persist through changes in underlying intellectual property ownership.

Crying Shame

The shame in all of this, on both the founder side and the investor side, is that there are plenty-good business models for open software, both for early stages, and to grow into. There’s a lot of work to be done, trying out new models and variations, and figuring out what works. All of that is opportunity.

Dual-license under a strong-copyleft license. Build a “closed shell” around an existing, permissively licensed open core. Start source-available, and transition to open source once you’ve done enough market research to launch a new paid offering. Sell hosting, and run hyper-lean. That is by no means an exhaustive list. Read around.

Open source is a financial handicap under traditional business models. By giving the ability to use your software away for free, you forgo the means of compensation best aligned with value delivered. But open source can be an opportunity multiplier overall, if you can think your way out beyond traditional models, and have the guts to stray from the herd. It depends on the kind of software involved. It depends on other practical needs, like technical or regulatory requirements. It depends on the state of the preexisting market.

Overall, open source in business planning needs to feel like a coincidence: open source distribution happens to solve the system of equations facing your business. There are no points for forcing open source onto your problem, because you want to do open source first, and a business takes customers. There are no points for avoiding this conversation, postponing it, or delegating it, especially to a hypothetical acquirer you can’t yet name, and may never meet.

Get Wise, Pick Wise

In many cases, open source companies that take outside angel funding will end up “stuck” somewhere between insolvency and the high-multiples that attract venture capital, and for which that funding model makes sense. There’s no shame in ending up as a self-sustaining business, earning revenue in excess of your expenses, keeping good people employed, and churning out valuable open source, products, and services. Even though that isn’t how many angels define success, liquidation payouts are often zero or paltry when early-stage investments come due. The SAFE is better in that loss on an angel start-up bet doesn’t deprive the world of a good small business.

But the point isn’t that angels should suck it up, stop funding open source companies, or gum up the investment process with negotiation of more exacting terms. The point is that:

  1. Make Open Source
  2. Achieve Massive Adoption
  3. ?
  4. Profit

isn’t much better than the Underpants Gnomes. Don’t feed the Underpants Gnomes.

Angels should fund those who know and show better. Making software is never easy, but compared to making a self-sufficient business, achieving popularity by giving valuable things away for free isn’t that hard, especially if you’re funded the whole time. When it is hard, it is hard in very different ways than business. It’s important to identify teams that can see broadly felt needs, or create new ones, and fulfill them efficiently in good software. But when open source is involved, conversations on making money can’t wait until the seed round. Open source breaks the obvious connection between need fulfilled and money earned.

Making open source a business is a downright momentous decision. It means embracing a much harder combination of problems, with a lot less business prior art. Those inspired to shoulder the double burden of that complexity and run with it are great candidates for early-stage, high-resolution investment. Every angel dollar fed to those who ignore the complexity of that problem set, or especially to those who consciously downplay or fib their way around it, is a dollar that should have gone to someone attacking the problems business doesn’t yet know how to reliably solve.

Should have for the founder’s sake. Should have for open software’s sake. Should have for the angel’s sake.

Your thoughts and feedback are always welcome by e-mail.

more articlesrevision historyback to top