Well Meaning Sustainability Indistinguishable from Graft

#1

I am in a terrible, sad mood. And very liable to overdue the negativity here. But one thought definitely jumped out, reading through this blog post:

reach out to the maintainers and offer them generous speaking fees for remote talks to your engineering team.

If you can make sponsorship happen, great: you should do that. But if not… how about reaching out to the maintainers and offering to hire them for an hour-long “consultancy” speaking engagement instead?

Scare quotes are scary.

This isn’t about negotiating the best speaking rate from someone who may never have been paid to speak before. This is about compensating them for the enormous value that your company has gained from their work, and using a clever accounting trick to do so. So offer them a generous fee up front! Paying over the odds should be part of your goal here.

At least here in the US, “speaker fees” have become a public watchword for corruption. In really egregious cases—like those of pharmaceutical companies bribing doctors—the innovation went still one step further. Pay them to speak at an event, but simply don’t have the event.

I’ve tried to spread the point as broadly as I can that detecting shenanigans like this is a big reason big companies have big pain-in-the-ass payments and approvals processes. As quick as we are to call crypto exchange holdings and key escrow service accounts “natural bug bounties”, or to eat up movies about bank or casino heists, the world’s large companies are giant troves of cash. Social engineering and otherwise red-teaming them to siphon off or divert cash is a constant international bloodsport.

I can’t help seeing that all this arises from fundamental unwillingness to charge for the thing that is useful. For various reasons, including having to suffer seeing the market price that work, when the work is yours.

#2

Before reading the article I had already come to a few conclusions about what they were really wanting.

It’s basically a low effort form of training. That is kinda worrisome because there is no way that it would have an outcome that is useful to those involved.

There could be a way to make this a service that can be easily offered, but it would need deliverables and objectives associated with it I would think. Preferably with tailored made packages to each companies usage of whatever it is.

1 Like
#3

In my experience, training for software people is really worth paying for only when the subject is general skills and techniques or when the training is necessary to make some piece of software useful.

In the latter case, training’s most often worthwhile because the software is badly designed for ease of use, poorly documented, and there aren’t good books or video tutorials available. A lot of huge, commercial programs are in fact badly designed and ossified, so there’s a lot of training for them. Open source programs that drive good training business tend to have complicated configuration systems, accreted bit by bit over time without redesign and big backwards-compatibility incentives, that you have to figure out to get the software to start working in the first place.

It’s quite another thing to essentially hire a mentor to level your people up. You don’t know what you don’t know, so you pay for a look over the shoulder of someone who does. Ideally, they also look over your shoulder, in the format of mentorship, a workshop, or “a lab”. But even this is usually way cheaper and more accessible when productized. Gary’s Destroy All Software screencasts, for example.

#4

I find it amusing that in the country with the most intense pro-capitalist propaganda, people would rather engage in corrupt behavior than simply add an innocent price tag.

1 Like
#5

As stated in the article:

The problem: Everyone agrees that open source projects deserve more financial support. Actually supporting projects can be surprisingly difficult though

What strikes me here is the moralizing tenor of the problem statement. Simon uses the word, ‘deserve’ over a more neutral option… like say ‘requirement’ or ‘need’ - and I take ‘deserve’ to mean ‘merit’.

What this swerves around is 1) historical privilege, unearned entitlements and advantages by accident of birth or accidental circumstance; 2) the socially constructed nature of ‘merit’. Merit cannot be objectively measured, it’s an aggregation of ideological commitments to what we might see as ‘good’.

In this context, what is ‘good’ is what will help some people make money. Who are these people? Why should they be paid, and others not? How should we decide? Cui Bono?

What would a ‘good’ outcome look like? Would we recognize success, if we saw it?

You attempt to answer this in the linked article:

One of the reasons I stress dual licensing as a model more devs should consider more often is[…] Companies pay you because your software is good and they want to use it[…]

‘Payability’ is a great concept for devs to get their heads around… it helps to focus on the transactional and technical dimensions of doing software engineering work, but this bit strikes me as a naive justification for a model that has yet to convince me, because I think that the underlying economic principles and their corollaries have not been reliably assessed. The problem statement then turns out to be something that possibly doesn’t need solving, and even if it were, it is impossible to solve, because of the moral ambiguities.

For example, who does the ‘wanting’ in these companies? Is it the board? Is it their consultants? Is it an eccentric billionaire blinding everyone with the Halo Effect?

Companies don’t want anything in themselves. Companies simply function to disaggregate society, by creating divisions and creaming off labor value from engineers, or ‘making profit’ (depending on your own political disposition).

It doesn’t seem to me to disturb what is a fundamentally flawed approach to constructing any business model, which is to assume competitive equilibrium is a universal truth, when it is observably a tyrant working in service of the resource protection instincts of the most well-to-do layers in society.

Much of the debate here seems to start at the level of the needs of the market, a concept which masks the interests of unknowable isolated individuals.

Sooner or later we must abandon ‘the market’ as a conceptual model of universal economic truth, ‘fairness’, or ‘reality’.

‘The market’, exemplified by what this or that company personifies is a socially constructed regime that masks systemic failure, corruption, bias and inefficiency.

Extending the legal personality of companies into unreliable areas, perhaps the most relevant here is the OSI’s OSD eccentricities in thinking companies having protected characteristics that can be ‘discriminated against’ along the same lines as human rights, or a company also being equivalent to being a ‘field of endeavour’- which by the way is, AFAIK only really relevant for patent applications, not copyright licensing.

If dual licensing is the answer, I think I’d need to know a lot more about the problem first, before I vote for it as the accepted answer.

#6

I think I agree with this. I’m aware, however, that there are two big looming issues:

  1. FOSS software is non-rivarlous, so pricing can be tricky if you want to make any significant part of the software open source.
  2. Payment frictions are a thing. Try using a privacy-enhancing VPN and see how 1 out of 3 credit card charges get declined or ignored. And I’m sure that ratio sinks if the developer is in another country. (Forget about Cuba, of course). And developers have to set up a bank account, incorporate an LLC, etc, etc.

Item 1 is much more important, I think. I think the public-goods-funding discussions at RadicalxChange and Gitcoin have some interesting solutions. One observation relevant to your post, @kemitchell , is that a lot of the ideas here involve grant-based funding or grant-like funding: the funding organization pays for specific deliverables (e.g., features) in advance.

Perhaps it’s worth dividing up some of these solutions into pre-paid and post-paid? Grants seem like they pay in advance. Open core/selling-exceptions is post-paid support for FOSS.

1 Like
#7

The map of business models I worked up on the L0 blog used the obverse of this distinction: does the developer speculate by investing time and effort into the software before payment?

There’s a strong intuitive affinity here that I feel but don’t understand. If you’re paid to code, you get seen as a worker, not an owner. If you code and then try to charge, you’re an owner. Owners can make money without working more hours.

2 Likes
#8

Put another way: if you’re paid to code on your own FOSS project, you get to run all the risks of entrepreneurship, without getting any of the benefits.
You just created a lousy job for yourself without any of the benefits of a normal job.

Scratch that! I’d rather be an owner.

1 Like