<< "Nothing to Hide"? | The roads I take... | Integration eines Magento-2-Webshops mit FreeFinance und selbstgebautem Warenmanagement >>

Ending Development and Support for My Add-ons

This has been a long time coming, actually, and recent developments just put the final nail in the coffin.

I am ending all development and support for my "extension"-type add-ons effective immediately.

This affects (daily user numbers according to addons.mozilla.org):
If anyone is interested in taking over development and maintenance of any of those, please let me know and I'm happy to convert their repositories over to github for easier working with them, and and the new developer to their administration on AMO and/or move them over to you completely.

I will leave them listed on AMO for a little while so people who want to take over can take a look, but I will hide them from the site in the near future if nobody is interested.

The reasons for this step are multiple:

For one thing, I just don't have the time for updating their code or improving them. My job is stressful enough that my head is overflowing with Mozilla-related things all the time, and my employer is apparently not willing to give me any relief (in terms of hiring someone to supplement me) that would give me back sanity, so I need to remove some Mozilla- and software-related thing from my non-work time to gain back a little sanity so that I don't burn out.

I am also really sad that apparently nobody finds the time or energy to make decent managing and notification mechanisms available for UI code around the new-style web storage mechanisms like indexedDB, appCache, or ServiceWorkers caching, while we do have quite nice APIs there for long-standing things like cookies. For getting Tahoe Data Manager (which was my most interesting add-on) to work decently, I would have needed decent APIs there as well.

Then, my interest for experimenting with code has moved more and more away from the browser, which keeps changing around me all the time, and towards actual web development, where existing code doesn't get broken all the time and your code is more isolated. As a bonus, I can develop things that run on my (Firefox OS) phone and that I can show other people when I'm somewhere. And even there, I don't get as much time to dig into stuff as I would like to, see above.

And finally, and that's why this culminates right now, I disagree with some pieces of Mozilla's add-on strategies right now, and I don't want to be part of that as an add-on developer.
For one, I think add-on signing is a good idea in principle, but not enabling developers to test their code in any way in the same builds that users get is against everything I learned in terms of quality assurance. Then, requiring developers and other users of unbranded (or early pre-release) builds to turn off security for everything just to use/test one or two unsigned add-ons just feels plainly wrong to me (and don't tell me it can't be done otherwise, as I know there are perfectly good ways to solve this without undermining signing and preserving more safety). And I also fear that, while add-on signing brings a lot of pain to add-on developers and will make us lose some of them and their users, we will not reduce the malware/adware problem in the mid to long term, but rather make it worse, as they will resort to injecting binary DLLs into the Firefox process, which is the primary cause of startup crashes on updates, and I will have more grief in my actual job due to this, next to Firefox losing users that see those crashes.
And on the deprecation of "the permissive add-on model" as they call it in the post, I think that the Firefox UI being written in web (CSS/JS/HTML) or web-like (XUL) technologies and the ability to write add-ons that can use those to do anything in Firefox, including prototyping and inventing new functionality and UI paradigms, is the main thing that sets Firefox apart product-wise from all its competitors. If we take that away, there is no product reason for using Firefox over any other browser, the only reasons will be the philosophy behind Mozilla (which is what I'm signed up for anyhow)and the specific reflection of those in some internals of the browser, like respecting privacy and choice a little bit more than others - but most people consider that details, and it's hard to win them over with those. Don't get me wrong, I think that the WebExtensions API is a great idea (and it would be awesome to standardize some bits of it across browsers), and add-ons being sandboxed by default is long overdue. But we also would need to require less signing and review for add-ons that are confined to the safe APIs provided there, and I think we'd still, with heavy review, signing, and whatnot, need to allow people to go fully into the guts of Firefox, with full permissions, to provide the basis for the really ground-breaking add-ons that set us apart from the rest of the world. Even though almost all of the code of my add-ons ran within their own browser tab, they required a good reach into high-permission areas, which probably the new WebExtensions API will not allow that way. But I also do not even have the time to investigate how I could adapt my add-ons to any of this, so I decided to better pull the plug right now.

So, all in all, I probably have waited too long with this anyhow, mostly because I really like Tahoe Data Manager, but I just can't go on pretending that I will still develop or even maintain those add-ons.

Again, if anyone is interested in taking over, either fully or with a few patches here and there, please contact me and I'll help to make it happen.

(Note that this does not affect my language packs, dictionaries, or themes at this point, I'm continuing to maintain and develop them, at least for now.)

Beitrag geschrieben von KaiRo und gepostet am 24. August 2015 17:14 | Tags: Add-Ons, Data Manager, download manager, Firefox, Mandelbrot, Mozilla | 4 Kommentare | TrackBack

Kommentare

AutorBeitrag

Giorgio Maone

aus Palermo, Italy

zitieren
native.js
Quote:
"The ability to write add-ons that can use those to do anything in Firefox, including prototyping and inventing new functionality and UI paradigms, is the main thing that sets Firefox apart product-wise from all its competitor."

This is my exact feeling and the rationale behind this proposal, which has good chances to be accepted, even if modified and refined:

https://discourse.mozilla-community.org/t/proposal-native-js-to-embrace-extend-the-webextensions-api/3457

Care to comment there?
25.08.2015 00:06

VinnyG

zitieren
Tahoe Data Manager & FF Add-ins
Agree with virtually all you posted re Mozilla direction. I used SeaMonkey for ~5 years, switching back to FF last year. The first difference I noticed and addressed was the absence of (Tahoe) Data Manager. That extension was/is part of my critical browser privacy portfolio of add-ons, along with AdBlockPlus, NoScript, RequestPolicy, BetterPrivacy, HTTPSEverywhere, and PrivacyBadger (yes, I am paranoid - but am I paranoid enough?). It appears that BetterPrivacy (LSO monitoring) is having issues with FF 42, and could be on its last legs. I guess that NoScript may persist because of its popularity, and possibly the EFF-sponsored add-ons as well, but the remaining proven, privacy-related extensions could all be in jeopardy. Sadly, I am more than ready to completely abandon Mozilla products on the basis of that organization's callousness to user privacy; all that is stopping me is finding a browser that is and will likely remain better in that respect.

-VinnyG
19.11.2015 13:23

Guest

zitieren
I am very upset with the fact that Tahoe Data Manager for Firefox is not developed anymore. It is partially broken on FF 42 (not sure about 40-41), but the main thing – removing cookies individually – still works.

To VinnyG: Try Policeman instead of RequestPolicy. IMO, it's much better than RP – Policeman is able to do everything that RP and even more (and that part is the best).
23.11.2015 17:44

KaiRo

Webmaster

zitieren
Quote of Guest:
I am very upset with the fact that Tahoe Data Manager for Firefox is not developed anymore.

The code is open, feel free to take over development and maintenance.
16.12.2015 17:13

Kommentar hinzufügen