Prefer open [source, data, documentation]
As a software consultancy, it is often the preference of our clients to build proprietary software as it is often in its proprietary nature that companies perceive software as creating value as “intellectual property”.
Proprietary software is of limited value to us and to society. It cannot be reused. Lessons cannot be learned, collectively, from closed code bases.
Proprietary data sets suffer similar but tangential diseases. They, too, live on only as long as the corporation which “owns” them survives. However, they may at least see public consumption through public APIs. In cases of narrow or specialized data sets, this may be enough.
Open source is commonly (if not ubiquitously) consumed. As far as libraries, tools, and generic services are concerned, it is also commonly contributed to by many companies. Open data, much less so on both counts.
Open documentation (text, audio, video, etc) is widely accepted and contributed to. This very website is an example of that.
Wherever possible, nilenso will prefer open technologies: we will avoid contributing to patents. We will encourage our clients to extract open source tools, libraries, services, and applications from their proprietary codebases. We will prefer to work with clients who exclusively produce open source (Free/Libre) software and/or contribute to open data sets. We will encourage our clients to open their code, if they can, and open their data sets, if doing so is safe and respects users' privacy.
- When nilenso builds any software, we will prefer to do so under an open license.
- When nilenso exposes a data set, we will try to do so under an open license.
- When nilenso release documentation, we will prefer to do so under the most liberal open license the author(s) is/are comfortable with.
Open documentation and open data have rarely, if ever, been points of contention at nilenso. Blog posts, articles, openly-licensed talks on youtube, white papers, and podcasts are baked into an industry built on information sharing. When consuming large data sets, open data is always less restrictive and causes us fewer follow-on concerns (legal, technical, and otherwise) that closed data sets do. It is natural as a software company to prefer that we work with — and contribute back to — open data.
Open source is more complicated. Although every single layer between our code and the hardware it runs on (servers, clients, and networks) is a built almost exclusively on free and open source software, it is always the “last mile”, where all our consumer-focused software lives, which is most difficult to license openly. This difficulty is twofold: we need not only convince our clients — we must also convince ourselves. “Selling” open source to our clients is not always an easy task: over simplification leads to a very common arguments.
“This [app/service/library] is too specific. It has no value as reusable open source”.
This argument is not incorrect. It is simply too crude to capture any meaning. It is also self-defeating in the face of coupling with any “intellectual property” argument. Let’s examine both.
It is “too crude” because it forsakes all parts, all components, and all wholes (Alexander) for a singular totality. Code is never reused in its totality. Perhaps one service is useful in the commons. One namespace. One function. Open source is capable of analysis at every granularity. Proprietary software cannot be analyzed or reused at any granularity — not even by its original authors.
It is “self-defeating” because the truth that any software package is not valuable when reused in its totality means it also carries minimal value as “property”. Most clients do not want to hear this. We also not want to hear this, as the engineers of such “property”. If we look to the crudeness argument we, as authors, may feel reassured. Our clients, not so much.
It is a difficult case to make but it is the case our industry is built upon and we will continue to make it.