Something that caught me by surprise was the release of libbdplus which happened almost exactly one year ago. This filled a gap in the free software community that had been open since 2007 when the first BD+ discs came out.
The story here is that Bluray discs won the format war against HD-DVD because they don't just encrypt their files with AACS. They include a diabolical piece of self-modifying code called BD+ which gained an early reputation for thwarting decryption efforts. For many years, open source Bluray decryption tools only existed for discs that were BD+ free. Those cracking tougher nuts had to use MakeMKV and AnyDVD which kept the source code hidden thereby making important knowledge vulnerable to censorship.
In 2009, when I first heard about VideoLAN's plan to develop libbdplus, the lack of a git repository was suspicious. Why would a group known for prompt code releases in all of their other projects suddenly decide to develop one behind closed doors? Especially the most anticipated advancement since libdvdcss. Years went by and rumours of an imminent release became less frequent. Not only that, but other BD+ projects ceased development because they saw no need to duplicate effort. By 2013, I was not just accusing the developers of changing their minds, but causing outright damage to free software in the process. The end of December 2013, when they released libbdplus after all, was the time for me to take it all back. But hey, it's Christmas... a time to be pleasantly surprised!
That Christmas, I also got into an argument with some Wikipedia admins and developers of the MediaWiki software who thought that it was okay to make search suggestions mandatory. I hate it when search boxes spawn a drop-down list and condescendingly try to predict what you are about to type. As soon as Wikipedia acquired this "feature", I navigated to the checkbox in Preferences > Appearance and disabled it. However, in MediaWiki 1.22 which came out in late 2013, the developers removed this option because only 112 active editors on the English Wikipedia were using it. This is about 1 in 300. While I admire the fact that they actually collected data, popularity is not the right criterion to use when dealing with options that are objectively good. Some points against suggestions are:
So when I suddenly noticed search suggestions with no way to turn them off, I went to the Village Pump to ask why. From there, a debate ensued and since not everyone knew about it, six people from the 112 joined in to agree with me. This debate continued on the bug tracker where the prevailing sentiment was to keep the code base as clean as possible. This invalidates the idea of adding search suggestions in the first place. If the devs really wanted a clean code base, they would've made the suggestions opt-in rather than opt-out. A small opt-out rate allows you to drop two or three lines of code while a small opt-in rate allows you to drop hundreds. Any time a feature has to be specifically enabled to be seen, a very small number of people are going to enable it.
Some people who wanted to hide the suggestions customized their Wikipedia profiles with a CSS hack. This was unsuitable to me for two reasons. Firstly, typing is still delayed because nothing stops the scripts from running when the drop-down list is hidden. Secondly, hiding the suggestion box does not bring back the history box so its strange absence is a constant reminder that you are using a cheap hack. Luckily there is a better hack that can legitimately turn off the suggestion code. With a bit of jQuery, the MediaWiki API can disable this and restore the search history feature as soon as the text input loads.