Looking for new maintainer
dequis opened this issue · 38 comments
Hey there! It's about time I accept that I am not going to give a fuck about this project anymore. I'm generally burnt out on open source and have zero motivation for facebook related plugins.
Not to sound too much like a job ad for an unpaid position but, what I would expect from a maintainer:
- Having nonzero free time and nonzero interest
- Actively using either purple-facebook or bitlbee-facebook regularly
- Know enough C to not merge PRs that do stuff like adding a sleep that blocks the main loop, or to know when to ask for help if fragile memory management stuff is involved
- Be able to make sense of the bullshit build system this project has
- Be someone I can trust (i'm so burnt out this is not a high bar)
I'm also fine with like, handing it over to someone I trust a lot but doesn't have a lot of time / doesn't know a lot of C but takes a conservative approach on merging things.
A lot of PRs in the last few years are like "update this user agent slightly" and it kinda sucks but we can probably roll with that.
Additional things I would really like to see in a maintainer:
- Willingness to revamp the repo structure and unfuck the build system (#516)
- Finish the work to switch to github actions (#517)
- Willingness to make a common repo that integrates purple-facebook and bitlbee-facebook codebases
- a lot of it is copypasted from each other, with different indentation and tiny changes diverging on each side, which sucks for maintenance
- Willingness to integrate the WIP work chat branch
- This is harder now with facebook removing free plans, but a free trial should do. Work chat is not that different.
- I think in the bitlbee-facebook repo that's already merged?
- Willingness and skills to reverse engineer protocol changes
- I have some old docs here https://wiki.dequis.org/notes/facebook/
I would like unicorns too.
Honestly this reads like a "for exposure" unpaid internship ad that requires 20 years of experience with rust, typescript and fortran. Just, you know, please do some casual reverse engineering in your free time to benefit the interests of this megacorp.
The less cynical side of this and the only thing that kept me going for a while is: bitlbee, pidgin and friends are, essentially, accessibility tools, for a broader meaning of accessibility than just blindness (although we do have a bunch of blind users), but other less visible disabilities too. So uh, there's that?
HI @dequis I think I can take this forward, I don't have worked on libpurple before per se but I have fair knowledge of Glib and GTK+ and of course C, I think getting to know libpurple API won't be an issue for me. I have been using this plugin from years now and would love to be of any help.
@0bhat hmm, maybe start by throwing some PRs or reviewing some stuff?
Alright, I'm gonna start with trying to fix the build system and get rid of this patches mess.
Please suggest if you want it in a particular way.
Is retaining author meta data important? Without that it will be much easier to shift this to some other build system, I'm planning to migrate it to cmake.
HI @dequis I think I can take this forward, I don't have worked on libpurple before per se but I have fair knowledge of Glib and GTK+ and of course C, I think getting to know libpurple API won't be an issue for me. I have been using this plugin from years now and would love to be of any help.
@0bhat Is your fork now the official one, or are you still working on it? If it's in release mode, should the main package readme be updated to indicate that?
No it's not yet. I'm still working on this, this is still the official repo.
Is retaining author meta data important? Without that it will be much easier to shift this to some other build system, I'm planning to migrate it to cmake.
Not sure whatever happened here, but the intent is for upstream (the pidgin repo) to split this out to a separate mercurial repository for pidgin3 and build it as a meson subproject. I have no timeline on that right now, but that is the eventual plan.
I hope you will find a new maintainer soon. We advertised this call too, because otherwise we will have to drop the package from Gentoo https://bugs.gentoo.org/830331.
Still nothing?
Does there need to be the same maintainer for both purple-facebook and bitlbee-facebook? Or is it just a wish for synergy convenience?
@usvi - @dequis can give a more complete answer, but in the meantime...
My understanding is that no, they don't have to be the same, however, currently the codebases and build systems are separate (this code checks out that code and then patches it, etc.) which makes maintainership of either/both very difficult and one of the hopes was to combine them into a single code base, so someone willing to do that would probably get the project moving faster and make it easier for outside contributions. That said, dequis has no time at the moment, any maintainership is probably welcome, even if it's just to move one or the other side along.
@1ay1 - just curious if you're still interested in taking on a maintainership role. I have some mediocre C skills and might be able to contribute, but at the moment the weird state of the dual repos mean I find it nearly impossible to find the code I'm looking for. Since you were looking at fixing that, I wanted to follow up.
When you DO pass this project over, consider making it under a new, independent account.
I'm starting to think we need to find an alternate solution to this situation.
You mean the situation of no one wanting to work for free?
Yeah I don't want to complain if someone does not have the time to look into these things. And I'm sure Facebook does not make it easy to do so either. I did switch to using WhatsApp (which basically everyone I used FB for can also use) since it has a maintained libpurple plugin. Using pidgin is still important to me since I use other GNOME extensions that let me reply from notifications and it really helps a lot not having to go back and forth to pidgin windows to chat. Can't believe KDE or other desktops don't have that kind of quick reply. Thanks for all your work on this over the years!
@dequis Just for my own clarity - is it a money issue primarily, or a time/interest issue? I've certainly paid/donated for a few features in the past and would be willing to do so again. My understanding is you simply don't have the time (and interest) anymore (which I totally get).
@greatquux & @usvi - it's quite complicated. Forgetting the hard engineering work of reverse-engineering various protocols and features and re-implementing them, there's a fair amount of just housekeeping and tech debt in this project that needs doing which isn't fun work. The build process for this is complicated and requires a pretty deep understanding of both the bitlbee-purple project and this one, which itself requires knowing multiple programming languages and build tools not to mention the fairly complex codebases themselves. Dequis did a write-up of the steps required to simplify all of that and make it nicer, but it's a lot of not-fun work. Addressing that would make it easier for various one-off or small contributors, which might then lead to someone willing to take a more active role... MAYBE. All of which ignores the really hard work of tracking down all of FBs changes to a completely undocumented and purposefully obfuscated protocol that changes nearly daily. And remember that all of this is open source a, unpaid, volunteer time.
I'm not claiming anything on anything. I'm not blaming anyone for anything. I'm not entitled to anything. I'm just sad. Mind if I tell why? I worked so hard on the 2FA code thing, got it working and wanted to share it for everyone. Now I'm probably the only person on planet having properly working bitlbee-facebook with 2FA. Just.. understand my interest, ok?
Lots of shitty infrastructure unfucking honestly sounds like me. Been doing it with C, C++ and Python recently 300 hours a month. I'll see when I'm down to more humane levels. I might step forward and volunteer. If that happens, I would appreciate someone to team-up and question my actions as I go.
I'll put my hand up here, and say that, whilst I was an avid pidgin user for a while, I had to succumb to the Electron apps, and latterly Ferdi for my 'modern' IM needs; however, I am prepared to step up and do some testing and perhaps code review, but I'm by no means proficient in C/C++ or modern frameworks, so am less useful in the code design/implementation phases of this project. So, if that helps get us off the blocks, let me know!
@usvi , you can always fork the project. I wouldn't mind using your fork for now.
@usvi , you can always fork the project. I wouldn't mind using your fork for now.
Heh, thanks for the confidence. I have a fork and branch for testing my code changes ( https://github.com/usvi/bitlbee-facebook/tree/automatic-2fa-tokens ). But I'd rather like "civilized" solution. And I have only the bitlbee part. I gathered that best course of action is to unify things? Maybe even under single repo? I need to read about how this was planned. In my opinion forking many times creates confusion and makes things harder and divides people into warring tribes :(
There is also great value in issue texts in both the existing repos. I would not want to lose those unless absolutely needed.
It's a good thing we got indication that the maintainer is still somewhat following. Lets see. I'm positive there will be a resolution later this year.
@usvi threw invites your way, does that help?
I gathered that best course of action is to unify things? Maybe even under single repo?
Maybe? Optional.
@dequis has offered to review PRs and provide direction in a few other places.
I probably said that in the past but now I'm not really up to any serious C code review.
I'll throw this out there before people get too invested in a new fork and then get mad at me later..
Pidgin 3 and Purple 3 are nearing an alpha. No i don't have a date, but I do have a [milestone in our issue tracker](https://issues.imfreedom.org/issues?u=1&q=(Scheduled%20versions:%203.0.0-alpha1%20)%20and%20(%23unresolved) which will ebb and flow until we get to a release.
The goal of the alpha is to have rough Pidgin 2 / Purple 2 functionality (mostly around messaging) but with the ability to add modern messaging stuff in the near future. We're also aiming to get the protocol API layer as close to final as possible because, as you may have guessed, most protocol plugins will more or less have to be rewritten. At least the parts that talk to libpurple. We're doing a lot here to try to simplify that work as much as possible, but it's going to require a lot of work from everyone to port to purple3 regardless.
Also fwiw, there has been some discussion between myself and another contributor about possibly writing a new Facebook protocol plugin that uses the web API instead of using MQTT like this one does. That said, it's only been discussed and I'm not aware of any actual code being written for it as my priorities are the alpha and the other contributors priorities are elsewhere as well.
Hope this helps :)
@usvi - there's no reason to fork, PRs here will do just fine. And now that @dequis has sent you invites, you can simply make a branch here for your work and merge it once you are happy with it.
@grimmy - Thanks for that, I had forgotten about Purple 3. That does change things a bit. I love the idea of using the web API, especially if there's some folks interested in writing/maintaining it.
most protocol plugins will more or less have to be rewritten. At least the parts that talk to libpurple. We're doing a lot here to try to simplify that work as much as possible, but it's going to require a lot of work from everyone to port to purple3 regardless.
This may not be the the best place to discuss it, but it has to be mentioned.
To most people, Pidgin is only as good as its protocol support, and the protocols that people use in non-corporate settings are almost exclusively implemented by by plugins. Unfortunately, it seems that the amount of effort that plugin writers are willing to invest in actively maintaining their plugins has been waning, and the "require a lot of work" part will limit Pidgin3 adoption.
@usvi threw invites your way, does that help?
Most certainly once I get fully rolling. Thank you for your trust.
@dequis has offered to review PRs and provide direction in a few other places.
I probably said that in the past but now I'm not really up to any serious C code review.
Ok, lets see if I/we can create a low-effort setting for wrapping up things.
Everyone else: Thank you also for your contributions and comments. I have a ton of stuff to read and comprehend.
Unfortunately I have to agree with @LurkerHub . For me, personally, I don’t need fancy new features or a different UI or whatever new-and-shiny is going into Pidgin 3. Sure I might find some of it useful, but if I could have three wishes for Pidgin, it would be:
- Make Facebook accounts stop complaining about TLS certificates
- Make Google Chat accounts show messages sent when I’m offline
- Make Discord not occasionally lose messages
So, basic functional stuff. And yes, I’m perfectly aware that those three are all third-party plugins, not shipped by Pidgin themselves, but as an end user, that doesn’t matter—I use the protocols I need to to talk to the people I want to, because that’s where those people are, first-party or third.
Unfortunately I have to agree with @LurkerHub . For me, personally, I don’t need fancy new features or a different UI or whatever new-and-shiny is going into Pidgin 3. Sure I might find some of it useful, but if I could have three wishes for Pidgin, it would be:
Fixed in purple3 by using the system certificate store instead of our own busted stuff.
Can't be implemented in purple2 in any reasonable way without serious breaking the API and therefore creating purple3 anways. That said, about halfway done in purple3/pidgin.
Related to the previous one, purple3 has a history api that can keep track of all of this whether a window is displayed or not and allows back loading of history as well.
So, basic functional stuff. And yes, I’m perfectly aware that those three are all third-party plugins, not shipped by Pidgin themselves, but as an end user, that doesn’t matter—I use the protocols I need to to talk to the people I want to, because that’s where those people are, first-party or third.
Understandable, but there's a lot more to pidgin3 than just the "whatever new-and-shiny" and the finding/updating protocols thing is something I tackled in this week's blog post that will go public on Thursday at 0500 UTC but is available for patrons now.
To most people, Pidgin is only as good as its protocol support, and the protocols that people use in non-corporate settings are almost exclusively implemented by by plugins. Unfortunately, it seems that the amount of effort that plugin writers are willing to invest in actively maintaining their plugins has been waning, and the "require a lot of work" part will limit Pidgin3 adoption.
I'm well aware of this and making things easier for all developers but especially protocol developers is one of the primary focuses when designing our new apis. Rewriting all of the parts that touch libpurple is a big ask, and they only way it's going to happen is if there's good reasons like better feature support and apis that offload a lot of work from the protocol developers.
I know it's easy to armchair debate this, but please follow the development blog on my patron (all post go public within a few days), check out my twitch streams where we developer pidgin3 and address these issues live, or the best option, participate in our new discourse so that others may see these discussions rather than having to find them in an issue tracker for a related project.
Good to hear! I admit, a week ago I didn’t know that Pidgin 3 was even a thing that existed. It wasn’t at all obvious that things that looked like bugs in specific protocol plugins (and as for fetching messages sent while I was offline, plenty of other protocols do it) and were reported as such (on individual plugins’ ticket trackers) are actually going to be helped by core changes, but that’s definitely good news.
Good to hear! I admit, a week ago I didn’t know that Pidgin 3 was even a thing that existed. It wasn’t at all obvious that things that looked like bugs in specific protocol plugins (and as for fetching messages sent while I was offline, plenty of other protocols do it) and were reported as such (on individual plugins’ ticket trackers) are actually going to be helped by core changes, but that’s definitely good news.
Pidgin 2 (and therefore purple2) were created in a time before historical messages where a thing and the API never grew support for it. But worse than that, the APIs weren't designed in a way to accommodate adding those features at all, which is why all of this has to go to Pidgin 3/Purple 3. I know it's a bummer that it's taking so long, but we only have 3 unpaid contributors and there's a TON of work to do.
If you want more updates on what's going on, I do a quarterly update call The State of the Bird that usually runs about 45 minutes describing what we've done that past quarter. You can find a youtube playlist here. We do also occasionally blog about stuff on the main site but that's not going to have development stuff.
It's not from scratch, it's in place, but there's had pros and cons. Either way, check out the state of the birds for more indepth stuff.
Is there any cooperation or cross-pollination with other multiplatform clients like Miranda NG?
(In the spirit of the Trillian/Gaim cooperation against Yahoo's blocking attempts)
Only when it comes to figuring out protocol stuff, that's why there's stuff like this repo and https://github.com/bitlbee/bitlbee-facebook. When it comes to the projects themselves, not really as they're all written in different languages.