New update sites for free of charge software

Today we have published releases for all of our public, free of charge software. All of that software now uses a new update site location. The previous update site, hosted on GitHub, no longer works. You will need to update your software manually.

Today we have released the following versions of our free of charge software:

  • Akeeba Engage 1.0.0
  • Akeeba LoginGuard 3.3.1
  • Akeeba SocialLogin 3.1.0
  • Akeeba Data Compliance 1.2.2
  • ContactUs 2.1.0
  • DocImport 2.1.2

The new versions are compatible with Joomla 3 and Joomla 4 – albeit with still experimental support for the latter since it's still under active development. The downloads of this software has been moved from their respective GitHub repositories' Releases pages into our site's main download page. This makes it easier for us to eventually provide PHP and Joomla compatibility information in one place and manage our releases with common tooling.

We also moved all of the downloads and update information from GitHub to our CDN. The downside is that you will need to update to the new versions manually. Download the new version from our site and install it on your site, without uninstalling the old version.

Why this change and why now

In the past, all of these extensions used a file that provides update information which was located in each software's public GitHub repository, in the master branch. The installable ZIP package file was uploaded to GitHub. Therein lied two problems.

On the technical side, the tooling to make a release appear on GitHub was precarious at best, relying on a GitHub API version which is now considered deprecated. In simple terms, automating the release of our software to GitHub would soon start to fail and we'd have to either do manual releases or move our releases and updates to our CDN.

On the non-technical side things are more complicated, nuanced and far more important.

The GitHub branch's name was chosen a few years ago without as much as a second thought, as a matter of technical convention. In fact, a few things in Git itself and GitHub rely on this exact branch name. To the best of my knowledge, it was meant to be used as an adjective meaning “authoritative” or “the one from which copies are being made from”.

The sad fact of life is that there is a proper noun in English that is written and pronounced identically. That proper noun comes with some uniquely toxic, historic baggage – not to put too fine a point on it, it is linked to slavery. Its toxicity is such that regardless of dictionary meanings, etymology, and good intentions, it will make a lot of people uncomfortable and evoke experiences of bigotry or worse for reasons that are fully understandable.

I have also found myself on the receiving end of bigotry – albeit a much lighter form that “only” involved verbal abuse, slurs and a death threat... I must admit I have not really felt fear for my life in a casual encounter or any of the large number of traumatic experiences people of color and minorities experience around the world on a daily basis. In all honesty, if I still feel mildly jarred by my past encounters with bigots eight years prior, I can't even begin to fathom the trauma carried by the victims of endemic racism and casual bigotry.

For the longest time our Terms of Service have included language that penalised bigotry with immediate cancelation of the user account without a second chance. The only exception we'd make would be for someone inadvertently using hateful language without realising it, giving them a chance to address it. Would it not be hypocritical if we didn't hold ourselves to the same standards?

I've spent the past several weeks thinking about this. On one hand, is it right to change a word based on what could be reasonably be described a misunderstanding of its meaning? On the other hand, is it right not to change a word even if it triggers trauma for so many people? I faced an inner struggle, thinking that whatever I do would be wrong. Until it finally dawned on me. There is nothing to weigh. There is really only one choice and it comes down to why I'm a Free and Open Source Software developer. I am here to help people.

Claiming to help people without being inclusive is deceptive at best. Being inclusive means taking affirmative action even if you are not personally affected, not offerring big words devoid of meaning. If you want to make the world a better place, you start with your own home and business. The evils of this world are not the product of a few people doing something big, but the product of most people not doing their small part in figthing it. To this end, I took the decision to eliminate the use of the aforementioned branch name, replacing it with main – something equally descriptive and with no racist baggage attached.

The downside is that by renaming the GitHub branch the old update sites are broken. Existing installations of our software won't update automatically until you install the new version. That's a bit more work for you – and for me, to be fair. If it takes breaking an update to shine a spotlight on the subject of casual racism I'm OK with it. If you choose not to use our software because of that I am more than OK with it, too.

Thank you all for your understanding and for helping us do our small part in abolishing casual racism.