> Why couldn't the people who evaluated those skills, demonstrated through those projects, pay the author?

You make it sound like the solution is obvious. It isn't. There are a lot of discussions that try to solve this problem, for FOSS as well as for other fields. Patreon, Gratipay, Crowd Supply and Kickstarter are just a few options that have tried to solve this problem with mixed success. There are many projects that are wildly popular or used in critical infrastructure around the internet that are chronically underfunded.

My opinion is that extracting funds from people online is a high friction event. When combined with FOSS projects that might be used by a large user base but where each individual derives benefit smaller than the friction of a funding payment, the project, or individual maintainer, has trouble with remuneration.

> "I am an exceptional coder with an unfortunate tendency to only consider the complexity of a problem or the elegance of a solution when considering the value of my work."

A pretty bad faith reading. Maintaining a successful (GitHub) project means dealing with community feedback, triaging and fixing bugs, writing documentation, popularizing/marketing and managing code contributions, at the very least.

> You make it sound like the solution is obvious. It isn't.

I explicitly state there are a "myriad of possible reasons" and chose to focus on a sub-set of them (again explicitly). What I did not explicitly state was that given the wealth of possible reasons that the reality is nuanced and non-obvious. So, I guess I agree with you? There is a lot of other discussions to be had.

> Maintaining a successful (GitHub) project means dealing with community feedback, triaging and fixing bugs, writing documentation, popularizing/marketing and managing code contributions, at the very least.

Ok, How about:

"I have all the skills to be a good team member with an unfortunate tendency to only consider my own opinion of what is valuable is when looking at work."

Looking at the author's profile at the year the author indicated, I see a monero (alt-tier cryptocurrency that was very popular at the time) tip bot and a runescape emulation server. These are both projects that would be exemplary of all those skills you and I mentioned and yet they show an affinity to working on "things I like" rather than things that have real world value. Later in their history we find other projects like emulating popular websites but those are not the "successful (GitHub) projects" they lean on.

As a hiring manager, I'd stand by my read.

Great coder... we need to interview and prepare for a lot of work on the soft skills of being a software developer.

Hiring is a crap shoot. I am very likely wrong about this instance BUT I still have to make a call looking at all the factors and I would be more comfortable with someone who seems less likely to need supervision even if they are less skilled at the "craft".

> but some of them are in the category of "the result has marginal value".

This is often false and lacks perspective too. Or closer to reality would be that people do use this work and simply don't pay for it. Maybe some complain if there is a security issue in a one-man-show library. In software this isn't unusual.

What you really mean is the "result is marginally monetized". Which itself has value ironically, but that is again a broader perspective.

What I meant was "the result has marginal value". What I allowed for was a "myriad of possible reasons" of which this was a subset (and not even qualified as a large subset).

I agree, there is another valid subset in those possibilities that can be described as "result is marginally monetized" but in this instance, with the projects shown in the article, I don't think we are looking at core software libraries that everyone uses and nobody pays for.

Of course, I didn't want to say it is entirely wrong. But not every project will be some foundational core project and you won't have one without the other. Neglecting such contributions because the authors might not do it for a marketable product is likely a sub optimal HR policy which leads to sub optimal business decisions and results.

We compare the usual corporate grind or corporate experience with these contributions. It is not the whole of problems in engineering hiring, but at least something to consider. The requirement of a product is an economic necessity but not something intrinsic to good engineering. And yet I think hiring decisions would strongly benefit to have further understanding of this particular value of problem solving, even if that alone doesn't meet the requirements of a successful business.

> Neglecting such contributions because the authors might not do it for a marketable product

If you look at the other thread you sill see that I am not neglecting these contributions. I am simply not valuing them MORE than what they actually represent which is only a subset of the skills I'm hiring for in a good software developer.

> We compare the usual corporate grind or corporate experience with these contributions.

That's a false dichotomy and one I do not support.

> The requirement of a product is an economic necessity but not something intrinsic to good engineering.

I disagree, good engineering is about making the best decisions given the requirements of the whole problem and the resources available. You cannot discard some of the requirements because they are inconvenient to your preferred solution. The correct solution has to take the whole picture in to account. Your work may be at a level where the economic viability is a very small part of the requirements but fewer people actually have that luxury than think they do.

It is not a dichotomy, these types of experiences are valued differently, where one is disadvantaged over the other. And the relevant dynamic how one kind comes at the cost of another is described in the article.

Sure, a challenge in engineering can lie in contraints and if these result in more efficient engineering instead of bad quality, it has merrit.

But the requirements for efficiency are an entirely different class for businesses and most open source projects.

Some developers need some breaks from time to time to focus on what is necessary. For the sake of business. You should get rid of that quickly if you contribute for free to a project you care about.

How much (in dollars) do you think the contributors of ffmpeg have made due to their work on the project? How much (in dollars) has that project contributed to the media ecosystem? The correlation is probably off by several orders of magnitude

I find it easy to hold these two thoughts in my head:

Some FOSS projects are unable to extract a "fair" share of the economic value their product creates.

Some FOSS projects have marginal or non-existent economic value.

Looking at the article, I see more of the latter than the former. If this had been an opinion piece from Fabrice Bellard, I probably wouldn't have the same critical read. Also, Fabrice has had no problem finding gainful employment. Coincidence? Who knows.

Fully agreed, but without seeing his actual projects, who can say?

There is a screenshot of his profile in the article. You can pretty easily find those projects by typing in the org and username into GitHub. This was the route to check myself before responding.