As for the structure of this article. First, I will discuss each talk in order of appearance. Second, to determine what’s on the mind of policy-makers, I will list a series of terms that were emphasized across multiple talks. Take their emphasis as you will. Third, I will make some remarks of my own about what I thought might have been interesting to discuss during this meeting. I did not put forward my remarks during the conference due to the time-crunch most speakers and attendees were under. Instead I delve into them here. Finally, I list my key takeaways of the meeting.

Talks

European Commission Opening Statement

Speaker: Pearse O’Donohue, Director for Future Networks, European Commission.

Pearse’s opening statement mainly revolved around the importance to put OSS on the forefront of EU Policy where possible. He stated that the OSS community should challenge the European Commission (EC) and a focus should be put on how OSS plays a role in the EU. Specifically he mentioned that OSS plays a role economically, as evidenced by the market study discussed later during the meeting.

He stated that the position of the EC on OSS implies that it should be citizen-first, embrace AI, recognize digital transformation’s impact on climate change as OSS intersects with both subjects, digital skills should be prioritized by policy-makers and finally that OSS removes dependency on the supply chain. A worthy mention made by Pearse was one regarding Open Source Hardware (OSH). Which Pearse stated was: ”Certainly on his mind.”. It would have been interesting to see his thoughts on that subject. However, as the subject of the meeting was OSS not OSH it seemed natural to leave it at a mention.

I have no particular additions to make to his opening statement save for the fact that I see no reason for OSS and climate change to be mentioned in the same sentence. Unless you specifically wish to target climate change with OSS I see no reason to tie the policies to each-other.

The European Commission’s Open Source Study: Engaging the Community to Measure Impact

Speaker: Mirko Boehm, TU Berlin; Paula Grzegorzewska, Open Forum Europe (OFE).

This talk was split into two parts. During the first part Mirko Boehm spoke about his own views on OSS and OSS’s impact on society viewed from 3 perspectives; public, scientific and business. During the second part of the talk Paula Grzegorzewska spoke about a study yet to be conducted that would measure OSS’s actual impact.

During Mirko’s part in which he shared his views, one statement he made stuck with me. In the statement he paraphrased someone he knew as saying:

Open Source projects are incubators for technology and people.

He built upon that paraphrase by mentioning that many people he knew that were involved with OSS projects at some point, now held positions of high importance. Although clearly anecdotal, the statement stuck with me as I get the same feeling about OSS.

The remainder of his talk centred around OSS’s impact. In it he described 3 perspectives on OSS. 1) The public’s perspective, concerning the idea that protecting OSS should be a public interest since, in essence, OSS is a public good. Furthermore, it positively contributes to society implying common interest between OSS and society. Which should warrant protection of OSS as part of EU Policy.
2) The scientific perspective on OSS. Where OSS could aid towards Open Science, which is part of EU Policy. His view is that the scientific world struggles with openness and OSS could aid in achieving it. A statement with which I could not agree more.
3) The business perspective on OSS, where there is a conflict according to Mirko. As he stated that the central ideas of OSS; Openness and Fairness, do not mesh well with most business goals. As it requires sharing of one’s own technological advancements, potentially giving away a competitive advantage.

During Paula’s part of the talk she discussed that these perspectives required verification. As such, the EC had requested a study be done to measure the impact of OSS. Paula discussed the need for community contributions to adequately measure impact and a potential structure of the study as the study would most likely be used to inform EU Policy towards OSS.

I expected this talk to contain results of a study that had already taken please. Primarily because I had read a different title for this talk in a programme for this meeting that was published online. As such I’ve neglected to jot down much of the study’s structure. For those interested I suggest contacting OFE for Paula’s details and inquiring about the study.

Digital Sovereignty as Openness: Gaia-X and Open Source

Speaker: Peter Ganten, CEO, Open Source Business Alliance (OSB-A).

Peter spoke about a project called GAIA-X. An attempt of the German Federal Government, business and science communities, to bring digital sovereignty back into the cloud.

According to Peter one of the prime motivators behind this project is the influence the US has on EU policy, mentioning US sanctions on Russia in an attempt to force Europe to acquire American gas [ full story ] as an example. Undue influence of this kind can be seen in the cloud market, where US-based cloud-providers have a market-share of over 50%. US cloud-providers however, are subject to American regulation such as the Cloud Act, impinging on European data-protection laws such as the GDPR. The German Federal Government intends to mitigate this US influence with the creation of GAIA-X. Aiming to create a European-based cloud-infrastructure which would be subject to European regulations.

Furthermore, Peter went on to state that: “Proprietary software endangers digital sovereignty.”. Which is true to a certain degree. However, in the case of cloud-providers proprietary software is not the issue, the issue is the lack of influence over the providers through regulation. Peter proposed that GAIA-X could resolve this lack of influence by creating a federated and decentralized data-infrastructure in Europe. As for the use of OSS by GAIA-X, he mentioned that the use of CloudStack as one of the sub-systems in GAIA-X had been considered. By Q2 of 2021 we’ll see if this will be the case, as implementation of GAIA-X prototypes is scheduled for Q4 of 2020.

Considering the topic of the meeting I found that the talk was lacking in the specifics of the usage of OSS within the infrastructure. I can imagine this was due to the project only being recently announced (Q4 2019), however this should not have prohibited some brain-storming or further thoughts on possible use of OSS within the infrastructure.

Results of Open Market Study: Dyanamic Market Fueled by Digital Transformation and Innovation

Speaker: Stéfane Fermigier, President, French National Council for Free and Open Source Software (CNLL).

Stéfane’s talk was split into 3 sections, addressing 1) The size of the European Open Source market, 2) the results of a survey among 117 organizations concerning; how OSS is used, which OSS partners are contracted, how digital transformation impacted their OSS use and, 3) some specific information about the policies regarding OSS of 7 European nations.

As Stéfane made only a few remarks about OSS policy, and to avoid being long-winded, I’m not going to address all the growth numbers here. I’ve added the slides of the talk [ source ] and I’ll only discuss 6 major take-aways. 1) The use of open-source in the IT Service market is growing by an average of about 8% annually, with a projected market-value of 30 billion €,
2) both CEO’s and IT departments promote the use of OSS in their company, 3) the main motivations for using OSS are; provides solutions aligned with company needs, no dependency on external suppliers, cost-reduction, 4) the key factors for success of open source projects within surveyed companies are; security by design, compliance with regulations, availability of internal skills, 5) the lack of OSS skills hinders adption, 6) over 40% of the surveyed companies stated that for both digital transformation and innovation OSS plays a very important role.

Most of the results presented in this talk were not very surprising to me. However, what did surprise me was the market-value and the apparent gap in skills. For a market that has such value I would expect there to be more investment in closing the skill-gap.

Delivering an Open Digital Approach to Healthcare: How Open Source is Changing Digital Health

Speakers: Dr. Axel K. Braun, Coordinator Europe, GNU Health;
Stuart Mackintosh, CEO OpusVL, presenting the Dito Project.

Dr. Braum toke point on this talk stating it was was geared towards providing an overview of the state of OSS in healthcare. He led with some insights in the nature of “Free” vs. “Free of charge” applications. Stating that in choosing for these apps you need to be able to trust them.

He then gave 3 examples of apps and companies related to proprietary software usage in health-care related context. First, stating that health-care apps such as Vivy suffer from severe security and privacy issues. In the case of Vivy there were 2 glaring issues, 1) the app shared private date with 3rd parties and 2) the way public/private key sharing worked was misunderstood leading to severe gaps in security. Whereas the Ada Health App “merely” shared data of their users.
Second, on Dr. Braum’s list was Google. Where he stated that Google shares data with insurance companies, which may or may not, lead to a denial of insurance. Concluding with the fact that Google was in the process of acquiring FitBit and could potentially possess data related to their users health. Clearly putting their data up for grabs for insurance-companies.
Lastly, he mentioned the fact that Windows 10, was reported by DPO’s as in no-way legally operable under the constraints of GDPR.

Having outlined some of the faults of proprietary software Dr. Braum continued with the potential benefits of Free Open Source Software (FOSS) compared to proprietary software. Stating that for digital transformation to succeed you need control over the entire stack, both hardware and software. To illustrate this he mentioned GNU Health as a “prime example”. Written mostly in Python, open and free to use whilst using GNUPg for signing data. Covering most of the issues that proprietary software brings with it (no control, bad security).

So, “If the benefits of FOSS over proprietary software are so clear-cut, then why are are we not using it en masse?” was the follow-up question Dr. Braum posed. Taking a software developers perspective he listed 3 possible reasons, 1) the software quality is bad, 2) you won’t get fired for using proprietary software, 3) FOSS requires looking for the right software, whereas proprietary software is often presented to you by those who created it (FOSS is pull not push). Even-though there are downsides to using FOSS there are also chances according to Dr. Braum. For instances Open Standards can promote competition and possibly promote local economies by no longer having to use proprietary software.

In summary, Dr. Braum states that OSS can delivery on high security standards whereas proprietary software may not be trustworthy due to a lack of transparency.

Next, Stuart Mackintosh presented the DITO project, an effort to develop and share the best practices of health-care software. With the final goal of producing an application that proved that these best practices where indeed best practices. To demonstrate the methodology for gathering the best practices Stuart presented the case of a NHS application where health-care personnel stated that as part of the requirements of an application it should be as easy to use as a piece of paper. He then proceeded to explain how the Dutch Indicator of Worry archetype (DENWIS) provided a ready to use best practice that adhered to the health-care personnel’s requirements. As for the rest of the talk, Stuart was cut short due to some of the panel members at the end of the meeting having a strict deadline. However, he made it clear that the intent was the Open Source all of the code produced in the attempt to create an application that used the gathered best practices.

Now, in all fairness, both Dr. Braum and Stuart Mackintosh presented reasonable arguments for the use of OSS. However, neither of the presentations really grabbed my attention. Clearly Dr. Braum gave more of an opinionated talk whilst show-casing only high-profile cases. Which may or may not represent issues faced by most proprietary software. Whereas, Stuart’s talk illustrated how OSS can be a result of policy, by open sourcing all code produced for a government funded project. The reason they failed to grab my attention was due to OSS being either a conceptual alternative to proprietary software or a by-product of policy. OSS did not really take centre-stage, nor did they provide any comments about how they would make it so. Regardless, I enjoyed their talks for show-casing potential uses, benefits, and limitations of applying OSS in a health-care setting.

A European Digital Transformation in the Open: Open Source in the Manufacturing Industry (Panel)

Keynote: MEP Marcel Kolaja, Vice-President of the European Parliament.
Panelists: Helio Chissini Castro, Senior Software Engineer, BMW;
Lars Geyer- Blaumeiser, Senior Expert Open Source Software, Bosh;
Mike Linksvayer, Director of Policy, GitHub;
Deb Bryant, Senior Director, Red Hat;
Mike Milinkovic, Executive Director, Eclipse Foundation.

Marcel Kolaja started the panel with an introductory statement about how OSS changes the competitive landscape. For many OSS projects the companies working on a particular project are also competitors. Marcel likened this to the manner in which politics function in a democratic system. Delving deeper into the subject of the panel, he went on to explore how OSS relates the manufacturing industry.

For one, Marcel believes that OSS should be integrated in the Open Data policies and strategies of the EU. To illustrate his point he demonstrated the importance of OSS using Linux as an example. Stating that Linux is a pillar of the web due to its wide-spread adoption in web-servers. Showing that Linux is indeed a huge success. Having shown some the benefits of OSS he pointed out the shortcomings of proprietary software in the manufacturing industry. To do so he made the case that the Volkswagen emission scandal could have been prevented had the software in the cars been OSS instead of proprietary. Which may well have been the case, after all the scandal revolved around software alterations to reduce emissions when being tested. Unfortunately Marcel had to leave early due to other engagements. Unfortunate as I would have loved to know about any concrete plans he had to introduce OSS in such a preventative capacity.

The remainder of the panel-session entailed the usage of OSS by some major players in the OSS and automotive industry. For instance, Mrs. Bryant remarked that for Red Hat it was natural to give back to the OSS communities because it had benefited immensely from it. Furthermore, to her: “It [OSS] would be a form of R&D.”, when she mentioned her company’s funding of OSS projects. She went on to say that: “OSS in the automotive industry is going to be exciting!” since “Safety concerns are a top priority with many challenges.”.

Panel-member Lars Geyer- Blaumeiser spoke about the difficulties employees of Bosch had when they tried to convince upper-management to adopt OSS. However, after 2 long years of being faced with: “A management-wall”, Bosch had adopted OSS, started frequently pushing research to GitHub and, became a member of the Linux Foundation.

Next-up was Mike Milinkovic who gave a brief introduction for the Eclipse in Motion project, made up of roughly 5 working groups. 1) OpenMDM, a working-group developing a set of components used for composing measured data-management systems. With members such as Audi, BMW and, Daimler. 2) OpenPass, a working group dedicated to sharing methods for the evaluation of driver assistance systems and partially automated driving functions. With members such as the TÜV and Volkswagen. 3) OpenADX, a working-group aiming to deliver software tools and open source software for the development of autonomous driving. With members such as IBM, Red Hat, Microsoft, Bosch and Siemens. 4) OpenMobility, a working-group that has the purpose of advancing simulation environments for transport applications. With members such as; Bosch and the German Aerospace Center. 5) OpenGenesis, a working-group with a mission to provide knowledge, methods and tools for the assessment of artificial intelligence (AI). With members such as; TÜV SÜD, Mathworks, Intel and Bosch.

At this point the conversation among panel-members and the audience started revolving around why working-groups like these are necessary. As mentioned earlier by Deb Bryant, safety concerns within the automotive industry are a priority. AI in particular provides a challenge for the automotive industry. As currently most systems are deterministic, making them audit-able and demonstrable that they comply with regulations. AI systems however, are: “Non-deterministic and untraceable.” according to Helio Chissini Castro continuing with:“How would you verify regulations?”. Working-groups like those mentioned by Mike help to facilitate solutions for complex problems like these.

As the panel was nearing its peak-discussion an interruption was made indicating time was essentially up. Prompting a return to how the EU could take the lead concerning these type of developments. Panel-member stated that “It should engage more with OSS” and “Use OSS as a business driver”. Leading to a final remark by Helio illustrating the usefulness of OSS. He stated that BMW had open-sourced the complete code-base for the BMW i3, which in turn lead to the location of bugs and subsequent fixes. Which finished the morning the way I like it, with some bug-fixes.

Emphasized terms

For your consideration, I provide a list of terms I noticed being emphasized during the talks. Note that these terms were emphasized during multiple talks. I left out terms that were emphasized during one talk only.

• Policy (Obviously), OSS and the need for it to be at the forefront of EU Policies.
• Privacy, the impact of OSS on Privacy as OSS can be verified independently.
• Economy, economical impact of OSS, not just concerning cost-reductions in development.
• AI, in relation to OSS AI, policy towards it, its importance in the automotive industry and EU Policy to embrace it.
• Blockchain, in relation to decentralized OSS systems and as a solution for privacy, data-sovereignty and E-Idenities.
• Education, OSS, it’s usage in Education or lack thereof and the lack of skills concerning OSS.
• EU lead, OSS and how the EU could take the lead concerning policy towards it, as it did with the GDPR.
• Data-sovereignty, related to Privacy and OSS’s capacity to resolve issues where proprietary software shared data with 3rd parties unknown to its users.
• Open Hardware, put forward multiple times, not specifically addressed during any talks.

Remarks

Ownership

During the panel the impact and possibilities of OSS in the automotive industry were discussed. The subjects touched upon by the panel-members and the subjects of some questions towards them were geared towards safety concerns if the public had access to the software in their cars. To emphasize I’ve put “their cars” in italic, why? Because to me, this discussion was lacking a key element. Sovereignty and ownership. Whilst privacy and data-sovereignty seem to be at the fore-front of the minds of policy-makers, actual ownership and control over an object you have bought seems not to be.

For example, currently most cars on the market have some sort of on-board computer. This computer is loaded with software which, in some cases, controls hardware-components of your car. Say you’ve found an issue with that software due to some noticeable hardware malfunction. You, as the owner of that vehicle, cannot repair it. For one, it is copyrighted. Meaning that if you adjust it and publish how you did so, you will have infringed on said copyright and you are now a criminal. The best-case scenario would be that you might have voided any sort of warranty. Let that sink in. If you attempt to fix a problem with a car you own, paid tens of thousands of euros for you may either criminalized or your right to have it repaired may be retracted.

To me that’s unacceptable. How is it that I can fix hardware issues but not software issues? There is a flourishing market surrounding car-repair why shouldn’t it grow in size by allowing software alterations? After all, the car is mine, I didn’t rent it.

Takeaways

Note that these takeaways are the ones I find most important. I’m most certain that there are many others to be found in the wall-of-text above.

• OSS is most definitely on the mind of policy-makers in the EU.
• OSS is a major driving force of innovation.
• OSS is, in many cases, preferable over proprietary software, especially when regulations are involved.
• OSS has a growing market-share within the EU software industry.
• OSS may suffer from a gap in skills and education.
• OSS may suffer from a lack of adoption due to perceived flaws, such as stability and reliability issues.

All in all, as a software-developer, it was an interesting experience to sit in a room filled with policy-makers. The high-level problems discussed at events like these are rarely, if ever, similar to those that emerge in day-to-day software development and I must say it definitely piqued my interest. So, if you ever get invited to a policy meeting like this one, I can recommend attending it whole-heartedly!

The guide is meant to be hands-on and no-nonsense. I won’t go into too much, if any, detail about individual components and I will assume you’re familiar with the following:

• CentOS 7
• Snap
• Docker
• Kubernetes
• MicroK8s
• Nginx
• Nginx-ingress
• NodeJS
• DNS

NOTE: You can follow along on a different Linux distro or even Windows. I‘ve added references to installation guides at the bottom of each section where applicable. Windows users should skip to the Kubernetes section. I have not attempted installation on a OS other than CentOS 7 & 8. The attempt on CentOS 8 was unsuccessful due to a failure to install snap .

Pre-requistes

You have:

• Access to a machine running CentOS 7.
• Root access to that machine.
• A Fully Qualified Domain Name at your disposal.

CentOS 7

Snap

We’ll need snap to install MicroK8s. So lets install it.

• Login to your CentOS machine as root
• Run these commands to install snap and enable backwards compatibility with classic snaps:

yum install snapd
systemctl enable --now snapd.socket
ln -s /var/lib/snapd/snap /snap

• Restart your CentOS instance or start a new terminal session. This allows the snapd binaries to be loaded.
• IMPORTANT: Do not prepend sudo to the snapdinstallation commands. Follow this link to find out why.

Linux distros: Follow the instructions on this page to install snap for your specific distro.

Kubernetes

MicroK8s

We’ll need MicroK8s so we can run your personal website.

• Run these commands to install MicroK8s:

snap install microk8s --classic --channel=1.16/stable
microk8s.status --wait-ready

Windows: You will need multipass to install MicroK8s. Go to this page, follow the instructions and install multipass on Windows. When you’re done installing multipass, go to this page, scroll down until you see the Windows logo, click the logo and follow the instructions.

Nginx Ingress

To expose your Kubernetes cluster to the big, bad outside world we’ll need another piece of software. Kubernetes has a concept called an Ingress to do this. A standalone installation of Nginx could perform the same job in a non-Kubernetes system. So, lets have a divine union and use Nginx-ingress in your cluster.

• Run these commands to, alias microk8s.kubectl, enable install Nginx-ingress

sudo snap alias microk8s.kubectl kubectl
microk8s.enable ingress
kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/nginx-0.30.0/deploy/static/mandatory.yaml

Windows: If-and-only-if you’ve installed multipass you can follow the commands above.

Creating the necessary objects

Now that your Kubernetes cluster is ready, lets deploy your personal website. First we’ll deploy the NodeJS server hosting the website.

IMPORTANT: All of the files below contain a example.com string-value. Replace that string with the actual domain-name of your own personal-website.com. You should also replace the image heroku/nodejs-hello-world with an image containing your web-application.

• Create a file named deployment.yml and edit its content to equal the following:

apiVersion: apps/v1
kind: Deployment
metadata:
name: personal-website-deployment
labels:
uri: example.com
spec:
selector:
matchLabels:
uri: example.com
template:
metadata:
labels:
uri: example.com
spec:
containers:

    - name: personal-website  
      image: heroku/nodejs-hello-world  
      ports:  
        - containerPort: 5000

• Create a file named service.yml and edit its content to equal the following:

apiVersion: v1
kind: Service
metadata:
name: personal-website-service
spec:
selector:
uri: example.com
type: ClusterIP
ports:

- name: http  
  protocol: TCP  
  port: 80  
  targetPort: 5000

• Create a file named ingress.yml and edit its content to equal the following:

apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
name: personal-website-ingress
annotations:
nginx.ingress.kubernetes.io/rewrite-target: /
spec:
rules:

- host: example.com  
  http:  
    paths:  
      - backend:  
          serviceName: personal-website-service  
          servicePort: 80

• Now run the following command to create the Kubernetes Objects necessary for your application.

kubectl create -f deployment.yml -f service.yml -f ingress.yml

Networking

DNS

This guide assumes following DNS prerequisites.

• You own a domain-name.
• You’ve setup an A- or AAAA-record that refers to the IP-adress of your CentOS-machine.

Localhost

If you do not want to proxy traffic from example.com and you just want to fiddle around locally. Removing the hostkey from the rules map in the ingress.yml file should do the trick. I’ve only tested the DNS settings mentioned above so I cannot ensure it will.

Aaaaand boom goes the dynamite! Liked this post? Clap. Disliked this post? Comment. Have something interesting to add or have I missed something? Comment! I’ll always consider any of your suggestions and/or improvements.

In this article I outline my thoughts on implicit-versioning, specifically version-tags and version-ranges. In doing so I first give a general description of tags and their use for either identification or categorization, I describe what version-tags are not and what they are concretely. Second, I describe why you should avoid using version-tags for categorization. Third, I describe version-ranges and why you should avoid them as well. Last, I dig a bit deeper for those who remain unconvinced.

TL:DR?; Check out the summary at the bottom of the article.

Tags? Versions?

For those who are unfamiliar with the concept of version-tags consider this real-world analogue. Imagine going to an English auction with a “not-so-sophisticated” auctioning method, wanting to buy that amazing mint-condition star wars collectible you’ve had your eye on for years.
Before the auction starts all potential bidder signs up and is given a sign with a unique number on it.

The bidding commences and you hold up your sign at an amount you’re willing to pay. Other bidders out-bid you and you out-bid them. At a certain point no other bidders are out-bidding you. The auction is over and you go to the auctioneer to take home your coveted collectible. They check if the unique number on your sign matches the one they jotted down when the auction ended and tell you were you can retrieve the collectible.

The only reason this auctioning-system is working properly is due to the relation between the unique number, the sign and your ownership of said sign. The three together provide a means of identification through association.

• If some-how the unique number changed after your successful bid, and before retrieval of your collectible, you can say good-bye to Mr. Solo due to incorrect identification.
• If you lose the sign, someone else can pick it up and retrieve the collectible. Because he/she is now associated with the sign and the unique number.

In version-control systems version-tags are similar to the signs used in this auctioning example. As they:

• Can, but are not required to, be used as a means of identification through association for an object, e.g. a bidder with a sign, or a historic state of your source-code with a version-tag.
• Mean something in one and one context only, e.g. the auction you attended, or the source-code you’re working on.

Based on this example I define tags as: A means to identify or categorize an object, as does Miriam-Webster [ 1, See: 5a, 5b].
There is an important distinction to make between identification and categorization. When using a tag as a means of identification it should never be used in the same context again. When using a tag for categorization the tag may be used for many objects in the same context.

Version-tags are not..

Let clarify a distinction between a “version” and a “tag”. In most version-control systems a version IS-NOT a tag. A version is the historic state of your source-code. A tag is any sign that is associated with a historic state of your source-code.
For instance, in git a historic state of your source-code is always associated with one-and-only-one unique SHA-hash. This hash can only represent a historic-state because of its uniqueness, as this allows for identification by association. Unfortunately, as with most unique-identifiers, a hash doesn’t provide any meaningful information to a human-being. So git allows developers to add meaningful tags that refer to a hash. This gives tags their real strength. The capacity to give a clear meaning to an otherwise, for humans, meaningless identifier.
So when I use the term “version-tag” I mean the tag used to identify or categorize a “version”. The two are not to be interpreted as interchangeable.

This gives tags their real strength. The capacity to give a clear meaning to an otherwise, for humans, meaningless identifier.

Version-tags are..

So what are version-tags? Consider some version-tag examples of the two types of tags I discussed earlier. In the examples I use SemVer [4] as the versioning-schema. The following version-tags are what I consider to be identification-tags:

• Tags strictly following the X.Y.Z form, where X, Y, and Z are non-negative integers, i.e. 0.2.3 , 1.3.5, 6.3.6 etc.
• Tags that, SHOULD always resolve to the same version. Here I state “SHOULD” instead of “MUST” because some version-control systems allow developers to add a tag more than once.

Whereas the following version-tags are categorization-tags:

• Pre-release versions of the form X.Y.Z-abc form, where X, Y, and Z are non-negative integers with a hyphen and an alphabetic [A-Za-z] post-fix, e.g.: 1.0.0-alpha, 1.0.0-beta, 2.3.4-omega. Since some dependencies stay on the 1.0.0-alpha-tag for ages, even-though lots of code might have changed.
• Alphanumeric tags of the form [:.-A-Za-z0-9]e.g.: latest, default, node:8, wheezy, lts, latest-beta, etc.
• Tags that MAY NOT always resolve to the same version.

Why you should avoid categorization-tags

Imagine that you’re attending an auction where the auctioneer messed up. The auctioneer gave another bidder a sign with a “unique number” identical to yours! The auction might end up billing you for items you never even bid on! In this case we’re using the sign more than once in the same context when our intent is to use the sign for identification. This means that we ended up using the sign for categorization instead!

Unfortunately, there seems to be a rampant use of version-tags that are used for categorization in Software Engineering. Whereas these version-tags end up being interpreted as tags meant for identification.

The latest catastrophe

One example to illustrate why you should avoid categorization-tags in your dependencies is the use of the latest-tag. This tag is used in the dependency-management systems of Maven [2], NPM [6] and Docker [3]. The latest-tag is one particular seed of evil that can cause grievance to many a developer.
When someone uses the latest-tag what is expected is the latest version of some dependency. What often ends up happening is they get a version of the dependency that “just so happens to be tagged with latest” without any guarantees it actually is the “latest” version. This especially applies to Docker, where the latest-tag has become part of “standard” procedures and you can end up with implicit usage of the tag. Consider the following quote from the Docker Command Line Interface documentation:

To download a particular image, or set of images (i.e., a repository), use docker pull. If no tag is provided, Docker Engine uses the :latest tag as a default. [3]

If you forget to supply a tag, Docker simply assumes you require a version with the latest-tag. In this case you have no clue whether or not this “latest version” will break your system. In effect the dependency-management system has taken away control from developers assuming that they want to use the latest-tag. Even-though it has no reason to assume this! You might just have forgotten to supply a desired tag!
What’s even worse however, is that the latest-tag can be moved to a different version and it is not limited to any specific type of version. It could be any version, even a completely new major-version. This means you could now be facing breaking changes or bugs since you’ve last had to download a dependency using that ow-so-useful latest-tag. The latest-tag is a prime example of a version-tag used for categorization which is prone to be interpreted as a means of identification.
Obviously this is not a problem when you’re pulling an image for the first time in a fresh project. It is however problematic when you’re working within a larger project and you don’t add a version or fix the version with the latest tag. Most likely this issue will only be caught after you’ve created a new release for your project. If you’re lucky, if you’re not you’ll find out when it’s already in production.

Surprise! Since your last download latest-tag has been moved from version-tag 2.10.3 to version-tag 4.3.1! — Dependency developer

The latest-tag illustrates that using categorization-tags can negatively impact your applications. As it increases the potential for incorrect outcomes of your source-code without your knowledge.

Using categorization-tags for your dependencies implies you’re no longer in control of the correctness of your code. Instead you’re hoping that, god-be-willing, your dependencies haven’t introduced bugs in the version your dependency-management system has selected.. This in itself should be enough of a reason to avoid categorization-tags and use identification-tags as much as possible!

Version-ranges are (almost always) just as evil!

Dependency-management systems often allow you to specify “version-ranges”. For example, Maven allows the usage of [1.2, 1.3] which is equivalent to SemVer syntax 1.2.0 <= x <= 1.3.0[5] whereas NPM supports syntax such as 2.x [6] which is equivalent to 2.0.0 <= x <= 3.0.0 . Both of these version-ranges are prone to incorrect outcomes across builds because like categorization-tags, the dependency-management MAY NOT always resolve to the same version.
For this very reason NPM even has a package-lock.json which they recommend you commit to your version-control system. This file contains all the information needed to ensure that anyone pulling a version from your version-control system will have the exact same versions of its dependencies. In essence they’ve added a new file to solve a problem that would never have existed if they didn’t allow version-tags or version-ranges.
Now, version-ranges are not as “bad” as using the latest-tag because in most cases they don’t allow major version changes. However, unless you’ve specified a version-range for a very , very, very good reason, they can be just as evil. Most of the time there is no good reason to use a version-range for a dependency and you should just use a fixed version. Version-ranges should be an exception, not a rule.

Please, just avoid categorization-tags & version-ranges

Hoare logic applies

In Hoare logic so-called Hoare-triples are used to reason about the correctness of a computer program. A Hoare-triple is constructed as {P}C{Q}where P and Q are assertions and Cis a command. Command C is executed when precondition P is met. When we use Hoare-triples in determining the correctness of a program we want to examine whether post-condition Q holds after executing command C for precondition P.
Without going into to much detail, assume we have a desired post-condition Q and we want to ensure that precondition P is met. For this to occur we need to ensure that command C is known. Assume that command C is a method from a dependency where, the dependency-version has been specified using a version-range or a categorization-tag of the form >= 1.x. This means we can not be sure of the program’s correctness as time proceeds. As we cannot guarantee the program will use command C1.1.2 , C1.34.1 or C1.5.3! This situation should be avoided at all times!

Version-tags convey meaning

Version-tags do more than just point to a historic state of a dependency. Often they convey a very specific meaning. Assuming your dependencies adhere to a versioning-schema like SemVer [4], version-tags allow any developer to identify whether there are any breaking changes, added features, etc. in this version of the dependency. This information no longer available at first glance when you’re using categorization-tags like the latest-tag.
Instead you’re now required to go to check all the versions of a dependency to find the latest-tag and the version it is associated with. As a Software Engineer you should prevent yourself and your users from getting into situations where you are uncertain about the correctness of your source-code. Especially if no conscious preceding change was made by you or them!

Your team-mates will thank you for it!

If you’re using categorization-tags or version-ranges in your dependencies you will eventually get incorrectness among your team-mates without having made any changes to the underlying code at all! Imagine helping a newly recruited team-mate to get started with your development environment. You’ve cloned the repository you need, your build-tooling has just finished, you run it.. Everything is running! Nice! Your new team-mate starts getting familiar with your application. Then after trying it out for a bit, suddenly, it crashes! POOF! Magical isn’t it? Now you’re stuck trying to find-out what happened for 10–20 minutes. Eventually realizing the version of a dependency got changed to a new minor-version during the build. A version which, unfortunately, introduced a bug. All because your dependency-management system had your permission to retrieve the version it felt like!

To summarize

When specifying the version-tags of your dependencies (and, where possible, when versioning your own source-code) you should:

Avoid

• Any type of versioning that, over time, MAY NOT resolve to the same version. This can lead to an incorrect application due to changes in its dependencies.
• Categorization-tags, as over time they MAY NOT resolve to same version.
• Version-ranges, as over time they MAY NOT resolve to same version. Unless you’re really, really sure they won’t, in which case — use the fixed version they’re resolving to.
• I use, MAY NOT, because version-tags and -ranges can but don’t have to refer to the same version over time.
• The latest-tag. For the love of all that is sacred, don’t use it!

Use

• Any type of versioning that, regardless of point-in-time, SHOULD resolve to the same version. This ensures your application stays correct, unless altered by you.
• Identification-tags, as they SHOULD resolve to the same version, regardless of point-in-time.
• Explicit versions, as they SHOULD, resolve to the same version regardless of point-in-time.
• I use, SHOULD, because humans make mistakes and version-control systems are way to flexible concerning version-tags.

Agree? Disagree? Let me know and leave a comment!