I think the whole grants thing is an attempt to cover up the truth:

FOSS has no market value.

It's free because it's worthless because it has no scarcity. Only FOSS that hasn't yet been built has value, but how do you accurately judge the worth of something that doesn't yet exist?

You don't.

You judge the person who is offering to build it and you gamble on them. Which means that your judgement is only by proxy, and nepotism and misallocation of capital will be rife. The bigger the lump of capital spent on one person, and the more awarded at once, the larger the misallocation possible.

Reply to this note

Please Login to reply.

Discussion

How can something millions of people use every day have no value?

Because it has no scarcity.

The concept might have value.

The work (human or machine) put into creating the original code might have value.

Hosting the service, or some background processing, might have value.

Maintenance work on the code base might have value.

The code base, once it is published, can be copied an infinite number of times. It doesn't even have the scarcity of a nail or a tomato. You might eventually run out of copies of a nail or eat all of your tomatoes, and have to go to the store and spend money to get more.

How much does it cost you, to copy-paste an address, on your computer?

That's what the code is worth. Nothing.

That's how much you can demand for it. Nothing.

Here are the things, that the people dispersing grant monies tell us are true (because they genuinely believe it to be true), but that they actually have no evidence for:

1. People will not build something, unless you pay them to build it.

2. People will build better things, if you pay them to build it.

3. One person building 8 prototypes of a concept, over the span of two months, will invariably result in a superior concept over one that took a different person two months to build.

4. In an unstable protocol environment, you should work sloppily because things change fast.

5. 4 people building 4 implementations of the same concept is better than 4 people working on 1 implementation of a concept.

6. There is no point in investing in a firm architectural, quality control, and environmental basis for your software development. Just hack shit out. Way cooler.

7. Lots of lay users testing the software is always more efficient than one knowledgeable engineer testing the same software.

8. How much automated test coverage should your build server check for? Zero. Stop wasting time. Ship faster. Also, what is a build server?

9. It's normal for things to break, in the next version, that were working in the last version.

10. It is always better for a software developer to work on implementations for one protocol, full-time, in perpetuity. That way, he becomes a Protocol Implementation Expert.

That last one is particularly pernicious, but it doesn't make an iota of sense. I call it the Nostr Theory of Zero Knowledge Transfer.

That is like saying, a carpenter who wants to build excellent tables should only ever build tables because he could never learn to build better tables by occasionally building a chair or a bookshelf.

FOSS has no definable value, but an application or service does.

Code is cheap, but the ability to effectively and reliable improve, maintain, deliver, and support software services is actually quite expensive.

The ability to write software is not the same as the ability to deliver a service.

💯

It's similar to the VC model, just more ideological, with less money and no expected return. Startups have no market value at inception either, but someone has to be willing to missallocate capital for a potential paradigm-shifting innovation to be realized. The grant model has better incentives, imo (customer exploitation is rife when it comes to VC), but there definitely needs to be more of a focus on revenue across the board; otherwise, things aren't sustainable in the long run.

Well, I agree with that, but I'd say more of a focus on profits/returns than on revenue, specifically. Not all profits need to be financial, and not all financial profits are direct. There's nothing inherently wrong in being a bit of a do-gooder, but there should be someone on the receiving end of what you built.

There needs to be a handover from producer to customer, with some exchange of value between those two actors.

Completely agree; when I'm referring to revenue I mean a positive bottom line.

Quick story...

I once had two devs working on my team. Both (literal) geniuses. Have never met two people so smart who worked together as one mind...but that's another story for another time...

They clearly weren't challenged, and yet wanted to do more (and had some ideas). So I gave them Fridays...they could do whatever they wanted on Fridays. Work on any project, code anything they liked, play video games--whatever--but they had to come show me "something cool" in a couple of week (my exact quote).

Best investment I ever made--without getting into the details they created a tool that was mind blowing (that solved an unsolvable problem).

For as long as I was there, Fridays remained theirs.

Dev is art, and artists can create amazing things, if just given an opportunity.

Bitcoin?

Somewhat disagree. FOSS demonstrably has value. It isn't about what it costs, it is about what it enables. All the best things in life are free, not because they are worthless, but because they have become so essential as to become ubiquitous.

The rest of what you said is true though. You do need some kind of quality control and feedback loop. The trouble is that people will almost always select features over stability. That is true of both commercial and open source software. The only correction comes when you fail to retain users and the jump to the next shiny thing.

That's why you need a PO capable of advanced adulting, so that your project doesn't turn into vaporware.