[wanderingbort]

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.

[raxxorraxor]

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.

[wanderingbort]

> 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.

[raxxorraxor]

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.