This was a piece I had rattling around in my head for some time. It gets weak at the end, and has no real flow to it, but it’s interesting enough in places that I thought I’d clean it up and publish it. Enjoy my dark sarcasm!

---

In a mass-market scenario, the larger the population the higher the chance for one or more free software projects to appear.

Since software can, in theory, be inherited by additional programmers and indefinitely updated, even the smallest chance for a free software project to be created becomes an inevitability over time. This means that even a niche market scenario can have competition from free software.

A crowd of hobbyists will have more time and expertise for a general-purpose piece of software than a development house can bring to bear. Simply put, they can do it better.

It goes without saying that cheaper, better and more supported free software will eventually out-compete proprietary equivalents, displacing established businesses and markets.

How can this problem be addressed?

---

Knowledge ∞

Knowledge obfuscation ∞

Above all, remember that merely hiding knowledge is only ever a partial solution and must not be relied solely upon.

Restriction by planning

Fracturing knowledge into parts which are given to multiple recipients who themselves don’t interact is a way to help prevent that knowledge from being combined. This is especially effective when the fracturing isn’t known by any of the recipients. A good quality is for fragments to remain obfuscated even if one were leaked.

“Open secrets”, where the fact of the secrecy is public but the contents are not, such as secret ingredients or other such conventions, can also be used.

Planning ahead of time, such as with a non-disclosure agreement, is effective in many cases, however, knowledge obfuscation using forethought can have a number of flaws:

• Leaks via espionage.

• Legal loopholes.

  • This is partially addressed with additional legal scaffolding such as “If any part of this agreement is not legal in your area, the rest of this document remains in force.”.

• Perceived-ethical issues by the restricted.

  • For example, an employee could leverage then-secret knowledge as a way of making an ethical statement or pointing out a perceived ethical problem with the knowledge holders.

• Revenge.

  • For example, improperly handled dismissals.

Restriction by reaction

Having effective legal reactions in place to address problems of knowledge leakage after they have leaked is obviously no way to protect the already-leaked information. However, it can help protect still-obfuscated knowledge.

When properly planned, leaked unimportant, less-important or entirely fabricated knowledge can be used as a sort of honeypot (canary trap, traitor tracing) to discover leaks before more valuable knowledge is later leaked.

Knowledge can be uniquely-labelled via steganography. Some examples include:

• Printer steganography‘s “yellow dots“.
• Digital watermarking – Movie screener DVDs can have visual patterns — dots or other watermarks — which survive DVD ripping and video encoding (video remuxing).

• Trap street – Maps have unique roads, turns or labels.

If the knowledge is more physical — like a physical prototype or mockup — then shapes, colours and serial numbers or signatures are examples.

A reactionary tool can itself become like a planning tool when any sort of chilling effect takes place. React to one leak, and other potential leaks are given a protective chill. However, such a chilling effect has the same vulnerabilities as any planned reaction (flaws listed above).

Knowledge protection ∞

Proactive shielding can be done through intellectual property — copyright, patent, etc.

However, knowledge can also be protected from its use via certification, specification, trade union membership, etc. (e.g. who would trust the knowledge of an non-certified non-unionized “electrician”?)

Industry-recognized certification can be used to bar free software from recognition of authenticity. Examples include POSIX certification, and the Single UNIX Specification. When certification takes time and money, free software projects simply cannot participate.

Software license issues can be given relevance to the marketplace, especially when the marketplace has programmers who would want to integrate free software in their products. One example is the promotion of the GNU General Public License “viral” nature.

Lastly, it is extremely effective to protect knowledge through culture. Take comedy for example. It is currently an offence when a comedian “steals” the original work of another. However, in the distant past this was not the case. Comedy was considered public, and a comedian (bard, actor, etc) was celebrated for their performance and not judged on the source of their material.

Knowledge complexity ∞

• Create knowledge complex enough that it’s only attained by specialized training.

• Don’t discourage (or actively encourage) a mercurial market so knowledge must be continually updated. (more on this below)

The barrier can be raised high enough that only those working or intending to work in that niche as a profession are able to have or maintain the necessary skills.

The reverse is true for the mass market. Even with significant technical training required, the larger general population dramatically increases the likelihood of hobbyists contributing the necessary skills. Additionally, since a larger population can more easily collaborate on technical issues, they are less of a disincentive to free software.

Underlying market change ∞

A mercurial market is one way to make any unwanted-attained-knowledge nonthreatening. For example, the needs of consumers change and the knowledge needs to be adapted to service those new needs. However, it’s possible to make the application of knowledge change.

Fundamental computer hardware, operating system or API changes can render a significant amount of publicized knowledge nonthreatening.

However, note that the emulation of obsoleted platforms to address this problem is a primary interest of some software projects. The goal would then be to direct the users toward the moving target of proprietary software instead of the “old” emulated/stable free software. Vendor lock-in is one tool.

No matter how obfuscated, legally-protected or restricted by training knowledge may be, it can still, perhaps eventually, find its way to competition. A change in needs or application could make knowledge irrelevant overnight.

Being first-to-market, especially when foreseeing (or manufacturing) market changes, will help proprietary software stay ahead.

Legal tools ∞

It bears special mention that overt legal methods can backfire horribly.

Copyright and patents are important to reinforce, but the customary tool of inventing a legal fight in order to tie up an opponent doesn’t really work with free software. Often there is no specific legal target as such.

If attacked, a project can vanish, or be boxed up and moved elsewhere and relabelled, rewritten, etc. Sometimes an attack provides extra incentive for a project, breathing new life into it. Even worse would be publicity issues. Of all things, free software programmers have spare time and social networks, and will use that to their great advantage.

Carefully-crafted attacks against individuals can still prove very effective though. More on that later.

Social reward ∞

Monetary reward does exist, but social reward is the primary incentive for the development of free software.

It is a reasonable enough generalization to think of this social reward as scaling with the population to say that a niche market’s small user base provides less social reward. This is, however, sometimes wrong. The nature of some hobby programmers includes challenge-as-incentive.

Controlling groups and projects ∞

Software cruft and bloat ∞

Software has a tendency to rot over time, or have cruft left over from earlier planning processes or the like.

It’s possible to encourage cruft by partially contributing to a project. A partial-contribution can introduce some functionality, or partially replace existing code. Imagine a code base which has multiple authors contributing. Take some piece of complex code from an author which isn’t too active, and rewrite some of it. Drop it back in and suggest it as a replacement.

Having your own people “actively” participating in one or more projects may seem counter-intuitive, but there are advantages:

• Active contributors tend to displace other potential contributors.

• Active projects tend to dissuade “competitive” projects.

Design by committee is an excellent way to force compromises and push for feature creep to aid in bloat.

Bureaucracy ∞

Bureaucracy, delays, discussions on features and standards-compliance are all easily encouraged.

Persevere, and a project can be choked to death with delays. Your people can be there for the long-term, while “true” hobbyists get girlfriends, go to school, get married, get jobs or get hit by buses.

Controlling individuals ∞

Major problem with a software project? Hire its lead! As counter-intuitive as it may seem, an unemployed programmer can have their free-time tied up, helping stagnate a project. You may not want to hire them yourself, but it’s easy enough to pull strings through an ally or an agency.

The reverse is also possible.. applying pressure to their employer in various ways. Have a programmer’s time tied up, have them fired, relocated or anything creative.

The usual toolkit is also possible. Send in a girl or a thug, rob a house, etc.

Attacking tools ∞

Don’t overlook the potential of attacking the tools used by free software projects. This includes anything from hosting and bandwidth to wiping a database. Having a hand in the CMS, wiki, issue tracker or other software can also be useful.