In-tree Protocols

This article was originally posted on Patreon and has been brought over here to get all of the Pidgin Development/History posts into one single place.

A question that comes up fairly often is "Why don't you add so and so protocol in your source tree?" and there's a lot to unpack here, so I figured a blog post is probably the best place to do that.

But first, like most of these posts, we have to talk about some history. For the first few years of Gaim's life, we didn't really have a way to support third party native plugins. We had loaders for Perl and TCL which didn't need compiling, but native plugins were another story.

The official method for compiling third party native plugins was to put the source file (singular) into the plugins directory and then run make filename.so. When Guifications 1 grew beyond a single file, we added instructions for you to patch your Gaim source tree to shoehorn it it. We eventually worked around this in January of 2004 by making it compile out of tree, but you still had to have a configured and built Gaim source tree for it to work.

It wasn't until the 0.79.0 release of Gaim on June 24th, 2004 that support was added for out of tree plugins by adding a pkg-config file and installing the header files. This was roughly 6 years after the initial release back in 1998. So obviously for those 6 years, everyone aimed to get their plugins in-tree, because it just wasn't reasonable to package them or have users compile them which we learned the hard way with Guifications 1. Of course this also affected Linux and BSD distributions as well which meant that no third party plugins were packaged for them.

But getting your plugins accepted into the main source tree was also seen as a level of prestige and it meant that the Gaim developers would also be responsible for maintaining it as well. However, as you may have guessed, this just doesn't scale at all because aside from the core team having limited time and expertise, we don't always have access to the necessary services either.

This is precisely what's happened to the Groupwise, Sametime, SILC, and Zephyr protocol plugins over the years. While at the time it made things easier for the users as they didn't have to install any other plugins, over time they became a detriment to users as we literally couldn't find a server to connect to for Groupwise, Sametime, and Zephyr which meant we couldn't test if they even still worked. To fix bugs, we'd have to wait until a reporter had the time and patience to work with us so we could supply them with patches to compile and try.

But more importantly, these are projects have their own timelines and expectations that come with their own expertise. They can and do have issues that cause an immediate need to release and they should be able to do that. When they're in-tree, that means Pidgin has to be released as well. Pidgin is a big complicated program whose development branch may by in any random state at any given point. So it's much easier to release a stand alone plugin, but the bigger issue here is getting users to upgrade to that new version assuming they're aware of that new version in the first place.

We also ran into another interesting problem when it comes to the in-tree protocols. One of our Crazy Patch Writers had moved to the United States of America on an work visa and unfortunately the lawyers for their employer weren't comfortable with them working with our code base because of the legal gray area some of our protocol code falls under. So as one would expect, that contributor found something else to do in their spare time and haven't contributed to the project since. It's an understandable situation and there's no hard feelings, but that's a scenario we don't want to fall into again.

So what's the solution here? There's a few actually, but the reality is that Purple 3/Pidgin 3 will only be shipping with support for Open Source/Open standard protocols. The reasoning for this is that there's no legal gray area here and those protocols don't just randomly break because someone decides to change the way they work. This is also nice because anyone can read those standards/specifications and understand how the protocol is supposed to work which eliminates some of the issues with the more corporate based networks where there is a lot of tribal knowledge.

But how do we help users out when it comes to third party plugins? Again, there's multiple answers, some are better than the others, but our long term plan addresses all of this. Keep in mind this is all for Purple 3/Pidgin 3 as not much new has happened in the Pidgin 2 ecosystem for a very long time.

To get started, we're simplifying the build system so that it will be exactly the same on Linux, macOS, and Windows. Believe it or not, this solves a lot of problems right off the bat. Once this step is done we can provide build images for people to use for these platforms which means third party developers don't need to setup an entire build environment on every platform. This is great for the developers and needs to happen, but it doesn't help the users discover new plugins and keep them up to date.

To help the users out, we really need a plugin and add-on store. There's just no way around it. The store would allow us to build an interface into Pidgin and Finch for users to find plugins and add-ons as well as allow them to update them as well. Developers would be allowed to upload their plugins there and hopefully we'd be able to figure out something around reproducible builds to make this as safe as possible. It would have ratings and all that other standard app store magic, maybe even donations or payments some day too.

While there's been a lot of discussion about a plugin and add-on store, nothing has really ever come from it. We're going to need it for a Pidgin 3.0.0 final, so it may hit my plate at some point if we can't find someone else to knock it out before then. If this is something you'd be interested in doing, please reach out. But please be aware that this is a complicated project and I'm a busy person, so please keep that in mind before reaching out.

I hope this helps explain our stance on in-tree plugins better. Whether you agree or disagree, please comment below and let me know!

I hope you're enjoying these posts! Remember they go live for patrons at 9AM CST on Mondays and go public at 12AM CST on Thursdays! If you'd like to support my work, you can join find a list of ways to do so here.