Community FLOSS

There are many ways to do FLOSS organization that can be done at the same time, meaning that the FLOSS world can contain organization models that encourage small teams of developers to make money off of applications at the same time that there can also be ideas and infrastructure that encourage much more distributed development organization, where monetary compensation is of a much lower priority.

A big idea of this type of distributed development is to be able to create more advanced systems through more people cooperating on shared visions. Advanced software systems can be things that go beyond simple applications. It can be FLOSS infrastructure that would otherwise be thought to only be feasible if done by corporations or organizations with large sums of money.

This infrastructure can include development tools and ecosystems that build momentum for any particular license ecosystem - privacy philosophy - or software ethics philosophy. There should be room for these philosophies to be advanced in ways that people who share certain values, can bring to fruition with teamwork and vision.

Revolving Doors of Strangers

Distributed development anticipating larger numbers of developers means embracing conditions of this type of development.

• developers will overwhelmingly be volunteers
• developers will have less time in the week (being mostly hobbyists or after-hours contributors)
• where as much contribution as possible can be done in smaller portions
• still, some developers will have more time
• still, some developers might be paid
• developers will come and go
• developers will vary in skill level
• more developers will only come under certain conditions:
• the ideas can be communicated, shared, and understood
• the projects' appeal is translated
• the projects' importance and wider value is translated
• the projects' respective place in its wider software context can be appreciated
• the personal interest in having the software system is shared by many individuals

This requires showing a vision - delineating specific answers about big issues - setting apart macro level gaps and strengths for these respective visions - providing places and paths where the biggest ideas are shared.

Relative vs Absolute

Statistical representation can distort the simplicity of absolute value and absolute feasibility.

When talking about large numbers of developers with shared values, this not exactly about factoring in question of majorities and minorities - but mainly what it takes to produce something that is valuable to a good number of people who want it.

It is somewhat useful to describe the world of Linux or open source in terms of percentages, but it can also be damaging to comprehension and perception on an essential level. I do not think that overarching global-scale proportionality is half as important as people make it out to be with regard to accomplishing development tasks. A job's requirements do not regard percentages - just the work and the tools. 

"Absolute" Value

Absolute value is not about "absolute" as in infallible, or absolutely true description of value per se. "Absolute" is being used in terms of describing numbers in terms of relative percentages vs 

Common Sense Macro Priorities

There are overarching divisions of software ecosystems and intentions of usage around:

• device types
• license paradigms, such as FOSS vs OSS vs mixed
• privacy and ethics paradigms

Enter: Usage Realms

Usage realms help to clarify visions of realms of usage on any level, but in this post it is about defining larger macro-level realms that people desire to contribute to - in order to identify missing pieces of those realms.

In the case where a realm of usage would translate to desiring no telemetry for instance - or desiring a fully FOSS ecosystem, identifying a usage realm can be very helpful.

This is because a usage realm might not be singularly about what one particular license might strictly require - but about much much more than that - about how the subsequent software wants to be used as a macro category of software.

Each usage realm requires infrastructure, and this is a big problem in the software world. If people build large infrastructure that cannot comport to your preferred ethics or liberty of control over your hardware, then you have no choice in the matter.

While simply identifying a usage realm does not suddenly procure developers out of nowhere - it creates what otherwise is often stifled - a shared idea of an objective.