Analytics cask purge

[vitorgalvao]

Removing unpopular casks. 777 across all repos.

All of these casks had a fair chance, as no unpopular cask on this list is younger (as a cask, not as an app) than a determined threshold. The reduction in casks will make managing them easier, as well as remove casks for dead software. As an example, I’ve grabbed quite a few at random from the list that no longer worked but no one noticed.

Pinging @Homebrew/cask, as well as prolific contributors that might be interested (@core-code @suschizu @ran-dall @brianmorton).

For now (and this might be overzealous), lest someone try to game the system, I’ll keep the criteria private between those pinged, but the method used public information exclusively. I’ll add and delete a reply to this thread with the metrics, so that you get pinged by email. I’ll ask that you don’t share the details, and ping me in private if you disagree or if you don’t get the reply via email.

PRs for other repos:
Homebrew/homebrew-cask-versions#7331
Homebrew/homebrew-cask-drivers#945
Homebrew/homebrew-cask-fonts#1832

[core-code]

perfect sounds good.
the format is up to you, if i should remove the drivers/versions prefix or do other adjustments, just let me know.

[vitorgalvao]

if i should remove the drivers/versions prefix (…) just let me know.

If it’s all the same to you, then I prefer without the prefix, yes.

[core-code]

no problem, i've adjusted the scripts and uploaded the updated files

[vitorgalvao]

Rerunning the script now. I’ll resubmit and merge when it’s done.

[svenjacobs]

Not really sure how I feel about (regular) purges. I just noticed that the cask for Function Pilot that I contributed in 2015 has been purged. I just wanted to reinstall the application through Homebrew.

[vitorgalvao]

@svenjacobs You’re free to resubmit the cask. Assuming it still fits the inclusion rules as they are now, it will be reaccepted.

[svenjacobs]

@vitorgalvao I might do this but it doesn't make any sense if the cask is purged again in the future due to unpopularity.

[vitorgalvao]

It will be exempted from such considerations for at least one year.

[brianbrownton]

Isn't that what taps are for?

[core-code]

i don't want to sound negative or rehash old arguments but i am not sure if we are taking the best approach here.

the objective of purging casks is to reduce burden on the maintainers. however what we are effectively doing now is removing casks (even if they are effectively zero-maintainance!) and replace them with other casks that are even less popular and often more work than those that have been purged to make 'room for them'.

i feel this is a LOT more work than doing neither purging nor adding new (and unpopular!) casks all the time.

consider a recent addition - 'eaccess'.

according to cask stats:

eaccess
30 days: 1 (#5360)
90 days: 1 (#6394)
365 days: 6 (#5995)
Age: 123 days (added 2020, March 05)

i guess that single 90 day download is from me in order to help keep the cask updated.

according to our own [CoreCode] database this app is NOT in the list of the 60.000 most popular Mac apps. even according for demographics differences (which i am sure exist), i can guarantee that this is less popular than nearly all of the purged casks have ever been. and it is versioned and requires actual maintainance in contrast to a lot of purged casks. its just one example but i feel many of these cases occured recently. also i am not sure we are doing a service to the people contributing those new casks if they will be removed exactly one year after anyway.

purging only those casks that require actual maintaince (either having a version stanza or something like more than 1 PRs per year could be a metric) would make sense, no? also i don't think casks like 'eaccess' that have absolute zero popularity should have ever entered the main repository. i'd be happy to provide a weekly updated list of the most popular apps (any count you wish) if it helps with making sure we don't add 'zero popularity stuff'.

just my 2 cents. sorry for the noise if there is no interest in revisting this.

[vitorgalvao]

i am not sure if we are taking the best approach here.

I agree. I’ve been skipping the purge days.

purging only those casks that require actual maintaince would make sense, no?

Yes. That’s a next step, though I still have to think of the metrics to use.

having a version stanza

We encourage the use of version stanzas, so I wouldn’t want to make it a metric for removal.

also i don't think casks like 'eaccess' that have absolute zero popularity should have ever entered the main repository.

That can be a tough call sometimes. Many of the submissions we get are for apps that are unpopular now but will be popular soon (e.g. new releases with a successful Hacker News or Product Hunt launch). That said, if they were hosted on Github we’d apply the popularity metric (and perhaps give it a few days), so your point still stands.

i'd be happy to provide a weekly updated list of the most popular apps (any count you wish) if it helps with making sure we don't add 'zero popularity stuff'.

That might work. I guess two things would be helpful, always on the same URLs:

• A txt or csv file, so it’s a quick searchable reference for maintainers. Ideally: app name, homepage, (something more?)
• A webpage (so users can check before submitting). Ideally: app icon, app name, homepage, (something more?).

We should also make sure to point out those are guidelines and that apps are can still:

• Be included despite not being on the list, if a maintainer has a reasonable expectation it will be maintained.
• Be excluded despite being on the list, if by its complexity a maintainer predicts the maintenance burden will be higher than the app’s popularity.

[brianbrownton]

Is it not possible to have somebody that cares enough (like @core-code or others) maintain a tap of unpopular/borderline casks and only introduce them to the main homebrew cask repo once they pass certain public metrics (github popularity, downloads, whatever)? Or there could even be an official borderline/unpopular cask repo that is not actively maintained except by third party contribs until they are popular enough to graduate to the main repo?

[core-code]

That might work. I guess two things would be helpful, always on the same URLs:

i think all that data should be available and providing it shouldn't be too difficult

maintain a tap of unpopular/borderline casks

we have a very small collection of 75 casks on our server. unfortunately they are not a 'tap' and the vast majority are either unversioned or updated by a script.

Or there could even be an official borderline/unpopular cask repo

if there was such a thing i'd be happy to spend a bit more time on those casks to maintain them on this repo so that its (more) helpful for others. i am not sure if it is worth though if the casks have been 'culled' exactly because there is no interest in them.

[ran-dall]

Is it not possible to have somebody that cares enough (like @core-code or others) maintain a tap of unpopular/borderline casks and only introduce them to the main homebrew cask repo once they pass certain public metrics (github popularity, downloads, whatever)?

I do this on my tap. Currently, I only pull in things I find interesting but I probably should pull in other things as well. The benefit of my tap is that it can provide ML coverage for updates (at least that's the plan, I don't run it often but I could). That said, so far out of the few things I pulled in, nothing has really been deemed worthy to graduate to the main tap...yet.

[vitorgalvao]

We could make an analogy between open-source and gardening. Some people bring new seeds (new casks), others tend to the plants (maintaining them). Some do both, and we all split the effort for a healthy garden—sometimes I take care of your plants, other times you take care of mine.

The trouble with unpopular casks is they’re unmaintained. A user might submit them and never touch it again or even stop using the software (we have a lot of sporadic and one-time-only committers). If nobody else uses it, what the first user planted was a weed: “a wild plant growing where it is not wanted and in competition with cultivated plants”. It takes time away from the other gardeners and makes the whole project less good.

If an HBC maintainer (or prolific contributor) is the only user of a cask but they keep it up to date, I have no quarrel with keeping it in. Maintainers are people who made a commitment to the garden and have the knowledge and interest for keeping other people’s plants within reasonable effort. If they want to keep one of their own around, I trust they’ll care for it even if no one else does, or remove it if they no longer want it.

There’s no such assurance with random contributors, hence why I think those are justified to having a higher barrier to entry.

All this to say I don’t think an official repo for unpopular casks would make any sense. The whole point of keeping casks out is making everything else maintainable; such a repo would be extra work for zero gain.

[brianbrownton]

Totally agree with everything @vitorgalvao said up to this point:

All this to say I don’t think an official repo for unpopular casks would make any sense. The whole point of keeping casks out is making everything else maintainable; such a repo would be extra work for zero gain.

i think this is the benefit of the "official" unpopular repo - there are no guarantees or expectation of maintenance, but there are some people that do enjoying gardening weed ;)

And if a weed turns into a non-weed, it can be moved to the main garden.

[vitorgalvao]

there are no guarantees or expectation of maintenance

If it’s an official repo, it doesn’t matter if there are no guarantees—there will be expectation.

Again, if it’s official there’s no point to it. Official means maintainers will still spend time on it, so might as well have those casks in the main repos.

An extra repo is by itself extra work. It’s much simpler to accept something and remove it if it doesn’t work out than to add every garbage to a dump and move it to the main repo if it turns out it shines. Not to mention all the duplicate requests we’d get, and having to cross-check with that repo every time, and always having to point people to the other repo.

Your suggestion creates more work, when the goal is to have less.

[brianbrownton]

Understood, thanks for explaining!

[svenjacobs]

In case anyone came here looking for a cask for Function Pilot: I now added it to my personal tap.