An Obvious Take on FOSS Funding

The idea of trying to create institutions that are not corrupt, and who have the right priorities does not require any particularly ingenious skill - just people with a clue, who also have the willpower. 

That simple thing for FOSS will be what people call cult behavior. But it's just what all institutions with particular interests do - look out for their interests. For FOSS, that includes a much stronger focus on funding smart infrastructure chains and pathways. - Looking for logical gaps in applications and tools, and trying to fill them in.

In the case of FOSS, there is not a singular institutional form (as in non-profit, for-profit). If for-profits can do it, then more power to them. If non-profits can do it, then more power to them.

If development community can be see a mutual benefit to contribution, then more power to them for building the same things that the FOSS institutions are building: even the for-profits.

• Mozilla has bought into the AI buzzword, and that is troubling because of what it might symbolize in terms of the org's intelligence and basedness. They seem to be out to lunch. They are moving in the wrong direction. But it could get better. 
• Everything should be done to encourage Mozilla to see why the community might think they're off course, but in a mature and magnanimous way on top of all the pop shade tripe.
• (Mozilla catches a ton of pop negativity tripe without many mature suggestions. . .  But ok will they listen either way?)
• The Linux Foundation is doing 300 million a year, and this stuff is not in their purview?
• (Maybe they're even more beyond hope than Mozilla?)
• There needs to be a desktop foundation, or an end-user device foundation, which would include solving (enhancing) cohesion in native GUI infrastructure solutions that have a mission to carry FOSS values to that space.
• Any for-profit like Valve that can also overlap in purpose with FOSS values is great.
• Specific for-profits that more specifically align with FOSS values as a mission would also be great, such as store platforms and infrastructure, more like System76.
• Volunteer developers who group together to be greater than one developer, with more official and organized mission statements and core team member "hiring" processes that still allow organic contributions from the community.
• Knowledge of specific places (other than just GitHub) to go where you can create teams - join teams - support these teams. Some of these places exist.

Organizational Categories

• Non-Profit Institution
• For-Profit Institution
• Dev Collaborations
• Individual Devs

All these categories have the same thing in common in the context of FLOSS: Development can be opened up to a wider community, in addition to the core developer or developers.

Additionally, these communities or individuals may have some of these important core characteristics:

• Unofficial
• Official
• Semi-Official
• Organized
• Unorganized
• Board/Committee
• Dictatorship
• Delegated
• Distributed

These are obviously not mutually exclusive, and not all these characteristics effect funding techniques equally, but they are important to project and organizational reliability and longevity, as well as being important to other factors that might indirectly effect motivations to fund organizations and individuals.

Some Generalizations

The more organized and team oriented projects can be, the more likely they should be to acquire trust and funding from a community. If dev communities can create projects that inspire contribution, then there can be a lot of contribution from volunteers in addition to funding as a matter of will to see projects succeed and continue.

It seems that the natural motivation of projects and individuals would be to find more core collaborators that see the vision of the project, and to gain trust from the community of code contributors and funders to see longevity and purpose, and enhancement for wider purposes beyond simple ones.

Fulfilling wider purpose but staying modular and free might come at odds with each other. That is about technical knowledge and individual technology strategy to work with others to build compatible systems that can be div