The advantages of full freedom are not that difficult to recognize and describe. What's tricky is recognizing and characterizing non-free components in a mixed environment, plotting a course away from them, and then navigating that course successfully.
I was heartened to see, for example, the GNU project develop a rubric for just this purpose when considering online code hosting services.
Applying this sort of graduated analysis more generally remains a problem, but one I think is crucial. To that end, I drafted an outline to begin organizing my own thoughts and develop my own approach to thinking about and talking about incompletely-free environments.
I've had this draft sitting around for a while, now, and looking back on it it seems to me to have some value, or at least still to make sense to now-me even though it was written by past-me (which unfortunately does not always happen). So, in the spirit of release early, release often, I'm including it below.
The general idea here is that there are different levels of participation in free and open source software communities. At the highest level this can be broken down into:
- none
- use
- contribution
So, to flesh those out a little bit, and with no further ado (at least for the moment), an outline:
- none
- once common, now rare, with most OSes and services incorporating at least some FOSS
- use (consume)
- incidental (stealth, accident, happenstance, don't know it's FOSS)
- aware (know, but indifferent to it being FOSS)
- intentional (FOSS-as-FOSS deliberately sought out)
- Levels
- absolute terms
- relative to total software use
- binary only internal use
- bug reports as if an inconvenienced customer
- source code modifications (downstream use, as upstream see below)
- for internal use only
- binary only distribution
- contribution (produce)
- bug reports (with a care to providing useful information: complete description on how to reproduce and context, error messages, stack traces)
- bugfixes (patches for new or existing bugs)
- code review
- documentation
- reference
- howto
- integration with other software
- training
- new features
- port to new architectures
- upgrades to new versions of dependencies
- libraries
- build environments
- runtimes
- funding
- in house support of in-kind contributions (as above)
- external
- direct donation to developer(s)
- donation to support foundations
- customer of company contributing as above