Is this project maintained?

[afontenot]

I want to emphasize right at the outset that I don't believe project maintainers have any kind of obligation to the community to continue working on a project. I'm very grateful for htop and all the work that has been put into it thus far.

I was recently surprised to notice that there haven't been any new commits to the project in over a year, and issues and pull requests are piling up. One in particular I'd very much like to see merged, adding support for PSS: #843

If the maintainer no longer has time or interest in working on the project, would they support additional community involvement, or possibly even a community supported fork, in order to get issues quashed and pull requests dealt with? I don't have the skill to do that, personally, but as htop is one of the most widely used sysadmin tools, I'm sure people would step up.

If this is just a temporary slowdown in time to work on the project, I'd be happy to hear that too! Thanks again for htop!

[Jesin]

I have wondered about this for a while now. My pull request #917 is a simple 1-line fix for a leak of FILE objects. I have been using a version of htop with that patch applied since I submitted the pull request 9 months ago. I've also applied #981 since then. htop is still by far the best program for its job that I have ever encountered, and I'd like to thank the old maintainer for all their work on it. I also would like to know if they're OK, if they have any plans to continue maintaining it, or if we should find a new maintainer.

[etosan]

Maybe contributors with most patches accepted could step up and then try to approach Hisham? His activities bar is mostly green, maybe he doesn't have time anymore?

[polluks]

Maybe we should switch to https://github.com/XPhyro/htop-xphyro?

[DarthGandalf]

Or any other of the 604 forks here: https://github.com/hishamhm/htop/network
There are updates in some of them in June and July

[natoscott]

Maybe we should switch to https://github.com/XPhyro/htop-xphyro?

This fork (or a fork it forked from?) seems to have changed the license from GPLv2 to GPLv3, despite the original htop license being GPLv2-only.

[natoscott]

Or any other of the 604 forks here: https://github.com/hishamhm/htop/network

Would anyone else be interested in forming a group of maintainers? (rather than just a 1-person model)
I see someone (?) recently created a https://github.com/htop but did nothing with it so far.

I'd like to go through the Linux distro bug-fix patches and get them merged at least, and then complete the 3.0.0 release that @hishamhm started some time back...

$ git tag -l | tail
2.0.0
2.0.1
2.0.2
2.1.0
2.2.0
3.0.0beta1
3.0.0beta2
3.0.0beta3
3.0.0beta4
3.0.0beta5

... but I don't really want to be the only person working on this.

[polluks]

@DarthGandalf Well, not everyone who forks or commits wants to be a new maintainer.

[fasterit]

@hishamhm any comments?
TBH, I for my side would much prefer you to either continue maintaining htop yourself or accept a few co-maintainers into this repository.
I'm not to keen on competing patch queues and volatile upstreams.
DLange
(Debian maintainer of htop)

[etosan]

@natoscott - so do you consider yourself committed enough to lead group of alternative maintainers?

Maybe we should try friendly fork approach for some time and reach hishamhm later (for resync)?

[natoscott]

@etosan yes, I guess so. I tried contacting @hishamhm by email a couple weeks ago without reply.

My preference like everyone here I think would be to be sending PRs to Hisham, but if that's not an option I can take this on for now. I'd be more than happy to hand it back to Hisham if he has time for it in the future.

Is there anyone else available to help with maintenance? I'll attempt to make contact with github to find the person behind https://github.com/htop next and see if we can use that (still seems to be unused).

[fasterit]

@natoscott I tried to contact @hishamhm from the Debian side multiple times as well.

I don't know why we don't receive a reply and what the underlying issue is as he is frequently active in his business projects (which are hosted on Github as well).
So at least he's alive and working, which is good to know.

So - with the same reluctance that you express - @ginggs and me (DLange) are willing to support the fork. Getting /htop would be good to reduce the confusion that will happen for some time about what the "canonical" (sorry to Red Hat :)) upstream is.

[natoscott]

| So at least he's alive and working, which is good to know.

Yep, good to know - that's the most important thing.

| I'll attempt to make contact with github [...]

I've heard back from github - they say the "github.com/htop" account is indeed active, its just not publicly visible activity (presumably a paid account) - so we cannot use it.

In light of that news, I've gone ahead and registered the "htop.dev" domain and started setting up "github.com/htop-dev" starting from the last code and docs from @hishamhm ...

https://htop.dev
https://github.com/htop-dev

I've also done an initial review of the last ~2 years worth of pull requests. There are approximately 50 PRs(!) that are good candidates to be merged - clear bug fixes, and simple-or-in-demand features . :| I'll start working my way through those next.

| Is there anyone else available to help with maintenance?

@fasterit does "willing to support the fork" mean help with maintenance or mainly switching over to it in Debian? (i.e. do you want / need write access to the repo for development work?)

Is there anyone who has spent some time in the htop code and wants to specifically help maintain it? (respond to PRs, issues, etc). There must be folk who were involved in the various platform ports, at least ...?

Let me know and I'll start adding people into the organisation - I'm hoping to avoid the situation that if I can't keep it going in a few years for some reason that it stalls again.

[fasterit]

I've also done an initial review of the last ~2 years worth of pull requests. There are approximately 50 PRs(!) that are good candidates to be merged - clear bug fixes, and simple-or-in-demand features . :| I'll start working my way through those next.

Awesome, thank you very much!

| Is there anyone else available to help with maintenance?

@fasterit does "willing to support the fork" mean help with maintenance or mainly switching over to it in Debian? (i.e. do you want / need write access to the repo for development work?)

Yes, please add @ginggs and @fasterit to htop-dev. We should clean up the backlog first and then think about a new release.
If that turns out well, we'll package it for Debian and that way switch upstreams. Still not happy with this but it seems we have no better choice right now.

[natoscott]

Yes, please add @ginggs and @fasterit to htop-dev.

Done.

We should clean up the backlog first and then think about a new release.

+1 - since @hishamhm had created 5 'beta' tags for htop-3.0.0 already, I expect the first task will be to merge clear bug fixes, release 3.0.0 in a few weeks maybe (?), then circle back and (re-)consider feature work for subsequent releases.

Still not happy with this but it seems we have no better choice right now.

Agreed.

[gaod]

I'll keep contributing Ubuntu ppa & FreeBSD ports with new upstream.

[natoscott]

@gaod great - I've added you too. There's also a new #htop freenode IRC channel for discussion and coordination of our efforts. Please feel free to join us there!

[maxiberta]

Will switch the htop snap to the new upstream - edge channel first, then candidate and stable on next major release (3.0.0?). Thanks! o/

[bertwesarg]

maybe announce your maintenance effort on the ML: [email protected]

[natoscott]

maybe announce your maintenance effort on the ML: [email protected]

Good idea - mail sent now - thanks.

[hishamhm]

Hi everyone!

First of all, I want to say I am really happy with this development! This is truly FOSS working as intended.

Second, with that out of the way, I want to apologize for being unresponsive. After almost 15 years maintaining a piece of software by myself (with an amazing number of community contributions, of course! but carrying the maintainer burden on my own (and this is the not only project I've been maintaining mostly single-handedly for over 10 years)), one which started as a hobby and a learning experience, I gradually drifted away from it — the project felt pretty much "done" for my own use, and expanding it towards other horizons (such as the next branch in this repo) would be another mini-project in itself, that I kept meaning to get to it "one day".

At one point I realized that I had spent several months without looking at the "htop" folder in my mail client, and it felt like taking a sabbatical. At that point I thought, "well, that was refreshing": in the meantime I was able to branch out to new projects and new ideas (which I really want to be able to carve out time to explore!). I quickly looked at the state of htop repo, saw the mounting PRs... thought myself, at least there are no critical bugfixes like the macOS craziness I've had to deal with in #682 (wow, 2018! I guess that was one of the last things I did here). That macOS bug which was very symbolic of the type of maintenance work I had to deal with in htop at that point in time: bugs for other platforms, new features for machine configurations I can't test... you know, maintainer chores. Then I looked at the beta branch with unfinished work, sighed, and I thought "yeah, I'll get back to this some time". And then months flew by again.

During that period, the thought of handing over maintainership crossed my mind many times (as recently as last week, incredibly!), and I always thought "ok, but to whom? how do I go about this?". And then today I wake up to the news of htop 3.0.0, which I got via Twitter! And I must say, my immediate reaction was of relief.

I guess here it's a good point to make a note that might be useful for others: yes, burnout is a very real thing and for FOSS maintainers it can be hard to identify. I've experienced burnout at work before, and it's easier to spot — because of the performance pressures — and to deal with — because ideally you have a supportive organization around you. For FOSS maintainers, the best-effort nature of the endeavor in most cases may make it hard for you to measure that effort, to balance your sense of duty to a community (that at times you built yourself!) to that of the effect it has on you (as in "why did I start doing this in the first place"). If you find yourself looking at your own FOSS projects and sighing, I guess that's a sign!

Yes, it was reckless of me to have filtered all mail mentioning "htop" email to a folder (I realized that for LuaRocks I have different filtering rules where Github/mailing list/etc go to a folder but direct messages go to my inbox — that would have been a better idea!), and not looking at it for so long. I apologize to @natoscott and @fasterit who tried to contact me; I understand that forking the project must not have been an easy decision to make, and any response of mine might have made it a little easier.

I want to thank you all of you for taking on this initiative, starting from @afontenot for opening up this topic. I am extremely grateful for all the amazing feedback I've received for htop over the years. This has been by far my most successful project, it has brought me many many great things, and I think it's indeed flattering to see it forked — I remember now saying once in a discussion about FOSS that "if something is unmaintained and important enough, it will be forked". I guess this means htop is in a sense important enough to someone, and I'm honored for that. As I said above, that's FOSS working as designed. I'm certain I could have handled things better from my side, but I guess all's well that ends well!

I'm excited to see the project move forward, and I'm making myself available for any administrivia you folks would like me to do in the transition process (such as getting this repo transferred, so this one auto-redirects and the issue and PR history gets preserved, making the original website redirect to the new one (love the domain!), etc).

Thank you all once again, and here's to htop's future! Cheers!

[fasterit]

Thank you very much for the positive feedback, @hishamhm. We're happy you are healthy and have had very understandable but not critical reason for going under cover some time. And we are even more happy Twitter got you noticing us. That's probably the best thing Twitter has done, ever :).

I'll ping you next week and see whether your mail filter is a bit more gentle now :-). Have a great weekend!

[slacka]

@hishamhm
For the sake of the hundreds of Linux distros that use this package, could you kindly consider either

• Add @natoscott (and others) as a github contributors with admin permissions to this project
  Or
• Transfer this project and redirect users to https://github.com/htop-dev/htop

Either will greatly benefit users and maintainers of smaller distros. Continuing the development in its original location would be ideal as no work would be necessary for users or distro maintainers. Thanks for all you have done!

[DarthGandalf]

I think instead of 'closing' it it should be transferred there, to preserve numbers of old issues/PRs.

[fasterit]

I'm confident @hishamhm, @natoscott, @ginggs and myself can come up with a useful transition plan.

[netstx]

@hishamhm obrigado!

[josteink]

What I e done in the past, which I think has worked out well is to create a GitHub organisation for the project, and transfer the project-ownership to that.

And then provide the new maintaner(s) with full access within that organisation.

It will ease all kinds of administrative tasks, and providing adequate access to new contributors (or maintainers!) will be much easier, and much less breaking to the outside world. It also makes Github provide automatic redirects for people still using the old URL for the repo.

My 2 cents.

[franciskim]

@josteink yup, I agree and that allows you guys to take sponsorships as well

[Martin-Eckleben]

@hishamhm Thank you very much for all your hard work!