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.

I am using "absolute" in terms of describing sheer numbers that matter for accomplishing a given task. It is not about "absolute" as in infallible, or absolutely true description of value per se. And by contrast, "relative" would mean the use of comparative percentages.

In other words, when talking about large numbers of developers with shared values, this is not exactly about factoring in questions 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 exist with regard to percentages - just the work and the tools.

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.

Specifically with macro-level usage realms, they require greater and greater infrastructure the more core they are. This is a big problem in the software world if these get no attention. (Nothing large gets done.) And 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. 

Thus, the only option for developing lesser known kinds of infrastructure is to have people work together and collaborate on it. The adage that in open source, it is up to you to make it is still the only dependable truth of it. But with larger software systems, "you" means large groups of people - even if they are highly modular systems that work with each other. There has to be planning and design for any of these systems to function efficiently.

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.