I'm a former pfSense user that reluctantly moved to OPNsense a handful of years ago after a lot of bad press around Netgate started circulating widely causing me to believe that support for the community offering might wane over time. I was under the impression that many people had moved off of pfSense for home use. I'm surprised by your assertion that it "remains dominant" for free users, and I wonder how you might know this?
OPNsense has been rock solid for me, btw. I was reluctant to switch only because of the time sink and perceived risk. Nobody wants to spend a weekend debugging VLAN tagging on their WAN port or some such. Luckily for me, there were no such issues when switching over.
It also has a fairly simple from-source deployment with a fairly solid build script.
Sure, I can clone it and run grep/ripgrep - but sometimes I like the ability to search the code on the browser.
Is it only GitHub where this is a restriction or GitLab is similar?
You can also run something like your own copy of Zoekt and then ingest repositories on demand though it isn't quite as instant. But if it's code you're already using extensively, it seems like it might be worth it. Maybe you can write some boondoggle to automatically ingest repos based on dependency metadata, even.
I would submit that this change is entirely business-related: it's a power-play to make people create accounts and stay logged in so they can track you better. It is not that they cannot afford it, it is that they are enshittifying the service to further their interests.
If they were really worried about money, they could lock it down completely so only paying customers could use the service at all... and then they'd lose a huge chunk of customers and lose all the prestige they build in convincing a huge pile of the world's free/open source software to use them as their hosting. So they don't do that - they keep all the prestige and the network effects by seeming _quite_ open, but they'll lock down _parts_ of the experience to try and force specific behaviour.
> you should probably at least accept that service providers can and do change things like this.
Indeed, you should. It should serve as a wake-up call that other people's services/platforms aren't under your control, and you can't rely on them to meet your needs.
I think that sourcegraph maintains a similar quality OSS code search that can be searched for free but I have not personally used it.
Logins are per domain and per device, so I end up dealing with this 4x per day if I'm using GitHub heavily. It's unnecessary.
git clone --depth 1 ...GitLab has had this long time.
They chose to take the existing search away from anonymous users to drive signups and logins. "Sign up and log in to get improved search" is not as compelling as "sign up and log in to get any search at all"
There is too much stuff of GitHub. From a resiliency point of view and from a monopoly point of view this is bad.
I recently tried to get a small FOSS project to switch to Codeburg. The answer was "no" because the free CI for them let them catch some MacOS on Apple Silicon bugs (the devs don't have that hardware locally), and because they are already used to GitHub, making it easier to onboard people and review PRs.
In my project a considerable amount of stars come from blank accounts, that like also non-paying projects to avoid detection.
I moved to codeberg now for my non work projects.
Does someone take the mailing list updates and manually PR them into Github? I've never actually used a mailing list so I'm curious how it works.
Having done a similar rodeo in the past -- migrating a project to an actual code review tool that enforces some more rigid structure, over plain patch files -- the interim process will probably be something like:
- Previously, some key people were allowed to commit to trunk directly.
- They would read emails/patches, do code review, apply, and push them to trunk.
- For now, you can keep emailing people your patches like you did before. Nothing will change.
- But at a certain point, you'll have to use this new Other Method.
- So, you should probably get familiar with Other Method early, by using it in the meantime, so you can be ready.
- At some point, no more patch files will be accepted and you will have to use Other Method.
- In the meantime, the maintainers will do double-duty and handle both venues.
Most projects are small enough where the double-duty isn't so bad. Most people will switch quick enough and you probably aren't dealing with 1,000 patches. It sucks but the payoff is considered worth it.
Eventually once this is completed you can do things like stop pushing directly to trunk and handling all patches to main through the Other Method. But you don't have to do that. It does sound like they'll stop accepting email patches, though.
The real economic reason to open source part of your product.
Mercurial has many neat features, and I much prefer working with it. I don't think Git is all bad, but I do feel sad that it has basically become an expectation that you use it, to the exclusion of all other options.
If GitHub becomes shit I'm moving my projects off of there and that's that.