Blog Post: Payability, Form, and Substance

Thoughts from recent reading.


Thank you. Great synthesis.

Hmmm. Can we sponsor open source projects like we sponsor podcasts?

“We will mention you when we produce content”

The whole support and maintenance is basically contracting with undefined deliverables.

The part I am still grappling with is “you must want to create a consultancy to service corporates to get paid”. Nothing wrong with this, just that requires a lot of extremely entrepreneurial maintainers.

Or points to @dpc’s Making Open Source economy more viable with dual license collectives

1 Like

This is a fundamental issue for support, either as an actual support relationship or as “cover” for payment. Why throw money at projects just in case instead of as needed? Especially when the criteria for comfort with a sponsorship seem to track indicia of quality, likely corresponding to less ongoing support needed. The exception is “this is great software, but they make it really hard to configure”, a parasitic case.

How many times have I wondered if I should just hold Artless Devices out as an agency that can contract or employ maintainers and do deals with the companies. But a lot of that is basically Tidelift. And I don’t revel in the chance to do even more negotiating small deals with big companies.

Mike Linksvayer and I sketched a platform that would let devs declare “I would be willing to do W work on X project over Y time period for Z dollars a month”, and then let companies make commitments until the target is met, splitting the cost based on their commitments. But that had the same unappealing features, once the matchmaking process is done.

I completely agree with what the article presents.

I’d like to add one more crucial point. Even if you project is “payable” procuring it has a huge overhead.

Getting some stuff approved in a large organization is a headache. They often have byzantine processes with huge delays, while your deadline is in a few days. For a front-line developer that just wants to get their code working, it is not an option. They would rather write more buggy code themselves, than go through this process to obtain well maintained and tested library/tool.

Except for much larger cornerstone projects (literally integrated “systems”) software shops will just not bother paying you even if they could. That’s is why, IMO, bundling is necessary. Engineers can get their org to buy them one or more “essential bundles for their tech-stack and business domain”, and then just use what they need when they need.