GitHub's time as the "cool" option has ended. It has matured and moved beyond the early adopter community, and presence on it is no longer a social signal of any significant relevance.
I use GitHub to get work done, either on my projects or on others. I do not expect GitHub to innately provide me a degree of fun. That's the job of the projects, not of GitHub itself.
Zoom exited the early adopter phase this past pandemic. It promptly was given significant attention, reasons were found to declare it "uncool", and Jitsi was elevated as the next "cool" replacement.
This article confirms that GitHub is now exiting the early adopter phase. Significant attention is being paid to it, reasons are being found to declare it "uncool" — but, no replacement has yet been elevated as the next "cool" replacement for it.
> What will GitHub's replacement "cool" service be?
Hopefully this will be ForgeFed [0] standards support, allowing forges such as github, github, gitea, sourcehut, notabug, etc. to interoperate via ActivityPub-based federation.
ForgeFed opens walled gardens and allows anyone to interact with any repo with a single account regardless on where it resides. It is still in early development stage, but received funding from NLNet which will be distributed among contributors working on roadmap items [1]. Additionally feedback is requested via the Feneas forum [2] so make yourself heard :)
Last time I tried Github Actions I was shocked at how bad it was. Somehow over and under documented at the same time, and overly dependent on third party repos to accomplish the most basic tasks. I gave up and used CircleCI.
When I started using it it was free private repos and CI minutes.
Whilst GH has duplicated these features very recently, they are still things that are at the core of gitlabs offering, so are generally higher quality and better supported.
Gitlab is also open source, which lets me mirror their repo locally in case they die or remove a feature I use.
Oh, and gitlab isn't systematically racist, which is always a personal ethical win.
Shout out to sourcehut as a possible next cool thing - currently in public alpha
> Oh, and gitlab isn't systematically racist, which is always a personal ethical win.
Wait, what? How is GitHub "systematically racist"?
> Shout out to sourcehut as a possible next cool thing - currently in public alpha
Sourcehut seems like a niche product for a niche audience. That's not a criticism – if anything, that's a compliment because too often people with niche needs or preferences are left out in the cold, but I don't think it'll be anywhere near the "next GitHub".
They're probably referring to a code-of-conduct document which has been attributed to GitHub, although I believe the document is (was?) actually maintained by the TODO Group, of which GitHub is a member.
IMHO the gitlab CI service makes a lot more sense though, github has this weird concept of "Actions", and running CI/CD/... is some "shortcut" that was added as an afterthought because nobody could figure out how github actions are supposed to work for something simple as "please just run this script after each push".
It's really hard to understand what you're trying to say here. I use actions a lot. There is no distinction between actions and CI/CD here. The context of this blog post is a set of features that were added to actions (during the beta!) to better support CI/CD workflows. There is no CI/CD "shortcut", like you say, bolted on to actions.
The alpha was rougher (and completely different) but that's why it was called an alpha!
I guess what I wanted to say is that gitlab's CI/CD solution makes more sense because it was specifically designed for CI/CD, while I seriously didn't understand what problems github actions were intended to solve when the beta started. Only roughly a year later a simple CI/CD system was bolted on as an afterthought. This isn't a showstopper, but it makes the overall system needlessly complex and hard to understand if all you need is a CI/CD solution.
When I worked with gitlab CI, I've read through the documentation, understood immediately how it works, and had a pipeline up and running half an hour later.
When github actions was started, I approached it with the same mindset as I approached (for instance) travis.ci, AppVeyor or gitlab CI. But after reading through the github action documentation I had no idea how to make this work for a CI/CD workflow, so I ignored it and continued using travis.ci and AppVeyor for my github projects. Only roughly a year later the above mentioned CI/CD support was added to github actions, which finally made it useable in the same way as all the other CI services.
So my suspicion is: github actions was going to be a new "revolutionary" thing with a much wider scope than existing CI/CD solution. But most people didn't understand such a "visionary" concept, and instead just wanted a simple CI/CD service similar to all the 3rd party solutions that already existed, only better integrated with the rest of github.
And that's why I think that gitlab's integrated CI/CD service makes a lot more sense. It was much more focused on the developer's needs from the beginning.
Thanks for the reply. What do you mean by a CI/CD system?
I'm not sure what you think was "bolted on" to actions, could you be specific? Features have been added (during the beta and since) but I can't think of anything that could really be described as "bolted on". "bolted on" to me implies some kind of disharmony with other features, weird quirks etc.
> I seriously didn't understand what problems github actions were intended to solve
You can run arbitrary code in response to any GitHub repository event, and also cron jobs and external triggers (a GitHub app can POST to a specific API to trigger those style of workflows).
The code runs with access to GitHub APIs for your repo (it can clone it, leave comments, create new PRs, whatever), and in any event that is associated with a PR a check status gets added to the PR.
This is a pretty general-purpose tool and I think it's easy to imagine the kind of problems people would use it to solve...
> my suspicion is [...]
Honestly it sounds like you're not really familiar with it and have some strongly negative opinions. I'd recommend either giving it another look and putting aside your feelings or working on a more substantive critique...
I mean, I get the "new" Microsoft. And I get that this is mostly a street-cred move by them, and they'll try to not mess it up by interfering with it. But still. That's now. What happens when the next shake-up comes and there's a push by the accountants to make money off everything, that's the important bit.
It's like Atlassian taking over Trello. They'll mess it up, it's just a matter of when not if.
Just to clarify here. It's only been owned by Microsoft for about a year now.
Before that they were their own company. And as far as I know, the source was never OSS to begin with. Microsoft didn't swoop in and lock it down. It was already like that.
In case anybody wondered if Github was closed-source because of Microsoft.
Projects are settting up individual cgit, Gitlab or Bitbucket instances. Roughly half of the projects i contributed to now have their primary upstream outside from Github.
Bitbucket may not be in the spotlight (probably suffering from being Jira's sibling) but in my opinion its web user experience is more pleasant than GitHub's. I'm talking about branch visualization and operations, pull request creation, UI layout flexibility. Bitbucket feels like a sober and useful tool, while GitHub is more like a claustrophobic social network centered on code to me.
Atlassian products is a collection of poorly integrated and maintained applications each with serious issues which Atlassian refuses to fix. Atlassian is basically where things go to die.
I disagree with the parent that they're poorly integrated. They're probably better-integrated than most other options out there. IMO the real problem with Atlassian products is that individually they are not good. Confluence is a bad wiki, Jira is a bad issue/project tracker, Bitbucket is a bad source code management tool.
Individually they all have a lot of flaws to the point that if they only existed on their own, no one would use them. But features like native support for referencing Jira issues in Confluence and having them auto-update makes companies want to use it.
Part of it, I think, is the development tool version of "nobody ever got fired for buying IBM". It's considered the safe choice. Enterprise-y companies get wooed by all the "Atlassian consultants" floating around out there. The ecosystem is just designed to attract enterprise users.
> I disagree with the parent that they're poorly integrated. They're probably better-integrated than most other options out there. IMO the real problem with Atlassian products is that individually they are not good. Confluence is a bad wiki, Jira is a bad issue/project tracker, Bitbucket is a bad source code management tool.
Fair enough, I agree - they are not that poorly integrated as they are just really poor tools.
I have been a very happy user every time I used Atlassian products on their own, so bad are many of the in-house enterprise alternatives, or products like DOORS and Notes.
Each to their own, I guess. We use Jira and Confluence at my org. I personally don't make use of the integrations between them all that much, but I find them painful to use on their own.
Atlassian is better than the enterprise solutions which preceded it, but that is a very, very low bar.
Their tools are remarkably slow, with each page both being remarkably JavaScript-heavy and constantly reloading (the two should be mutually exclusive, right?).
They really aren't bad, and have some advantages, but they are not a joy to use.
Their abrupt cease of support for mercurial damaged it beyond repair for me and many others. They didn't even offer to migrate stuff with the click of a button, people started writing scripts to migrate, and while you are migrating, why not to GitHub which in the meantime also gained free private repositories?
> Their abrupt cease of support for mercurial damaged it beyond repair for me and many others.
I'm not the biggest Atlassian fan, but they posted in August last year, gave 10 months notice and cited that less than 1% of new repos being created are using mercurial as their primary reason for doing so. If you cared about a project, almost a year is plenty of time to move it. I don't think it's entirely unreasonable to sunset a feature that is not widely used by your users, not widely used outside of your userbase, and that requires ongoing maintenance that the other 99% of repositories could benefit from instead.
It was more like a community and they destroyed it. Less than 1% of new repos were mercurial (what a surprise with zero mentions of mercurial anywhere except small text and zero marketing and they didn't even have it in their self-hosted product), sure, but existing repos were the problem. Some abandoned ones are lost forever. At least archive them, offer a tar download, anything... People had to parse the issues, people had to parse discussions, all the settings, access rights... I think after a year they could put everything in archive mode, but no, they deleted it with no easy export.
That's not OK and I'm clearly very, very angry as a former user.
> I think after a year they could put everything in archive mode, but no, they deleted it with no easy export.
I mean, it's still there. If it's that much of an issue, and the tooling has been made by the community, you're free to archive it now. At what point is it ok for them to say "hey, we don't want to pay to store the data/keep the codepaths to display/interact with this data" anymore?
How many of those people were paying customers before this? I don't know the answer offhand, but if I had to guess, I'd suspect a small number of them.
> That's not OK and I'm clearly very, very angry as a former user.
I hope as a paying customer, you cancelled your subscription to them and told them explicitly why then.
> At what point is it ok for them to say "hey, we don't want to pay to store the data/keep the codepaths to display/interact with this data" anymore?
At the point when they make it super easy for the people to archive the data themselves. Code part is easy, PRs, issues and downloads are hard. See: Google takeout
> I hope as a paying customer, you cancelled your subscription to them and told them explicitly why then.
Not just even for me, I made my company switch to it, and we were also hoping support for mercurial in the future, but were okay with it not supporting mercurial in local deployments, we had our hg repos on bitbucket.org. When the news broke, I moved to GitHub and perkeep (for archiving all the JSON data that I painstakingly had to scrape), and my (now former) company found a smaller vendor that offered what BitBucket was supposed to offer but never delivered, only for 100x the price (although one-time, custom development for them).
Yeah, hatred mostly because Jira is the grand enabler of micromanagers and corporate accountability and a bit slow.
It can be whatever people want to use it for. The customisation and the key features of the tool are not bad. Then again, most tools are neutral until a person wields them.
True, those solutions are always horrible. Still don't like Jira that much. Every corp somehow managed to slow that system down to a crawl that using it became a pain.
Still a great fan of Trac. Old but gold, simple and fast. Suffers a bit from a historical focus on SVN, but can be adapted to git easily.
Firstly Bitbucket allowed free personal private repos, so many people who did not actually want to use it did for closed source projects.
Bitbucket has generally had the least pleasing UI, and the association with Atlassian sort of corporate feel made it seem uncool to a degree. It just didn't really feel great to use for me. I've used all 3 extensively.
I've transitioned with companies from Github to Gitlab, from Bitbucket to GitHub etc. but never to Bitbucket. In fairness I was using Gitlab during their great outage, so I can say that cool is not always reliable. And coolness fades and dies relatively fast.
"They violently break all the recent frontend best practices. Where is the React or Vie, SPA architecture, tons of JS?
There should be a federal law prohibiting making fast and simple UIs so that nobody will have concerns that the UI frameworks war leads us to great future." - viach https://news.ycombinator.com/item?id=20775549
I don't have a problem using the UI on mobile. And it looks nice IMO.
And the ability to create a repo on their site by just pushing to a remote with the right name[1] has really made it easier for me to use their service. What do you find confusing and poor about the UI? I find it straightforward and efficient.
Maybe I was being too critical - it is actually quite nice on mobile.
I do use the find-file feature on Github a lot, as well as the quick file editor. Both are missing here, but I kind of see that at least the file editor is not well suited to the projects ethos.
Instead it's owned by an abrasive difficult to deal with developer who will argue "you're just doing it wrong" with paying customers. Clearly things aren't exactly roses and sunshine here either.
Idk, I don't have the source for the conversation, but I suspect "direct" is being misinterpreted as "rude".
Using git and mercurial for large binary file storage is, 100%, wrong. Why? They're not designed for it, so they handle it really poorly. Hacks like Git LFS and annex were made for a reason.
From sourcehuts perspective, they need to serve all their customers, and an extreme performance outlier for a still small platform could degrade the experience for others by becoming a significant part of the server load. Thus, it's fair to say no.
You don't think it's strange for a service provider to tell people that "mercurial isn't suitable for this" (even though it clearly works, and has been working for many years) and "you're writing your program wrong"?
It's fine to not support certain use cases because it's too much effort or otherwise too expensive. It's not fine to, as a service provider, tell people that their programs are (and I quote) "wrong".
If you're okay with that then that's your choice, but for me it really turned me off sourcehut.
> You don't think it's strange for a service provider to tell people that "mercurial isn't suitable for this" (even though it clearly works, and has been working for many years) and "you're writing your program wrong"?
No, not really, if done politely. Which seems to be the case here.
It also might "work" to use a large crystal vase as a hammer, but it's still "doing it wrong".
If anything, I'd fault sr.ht for having too vague usage policies and then telling users they are in violation of said policies. That's not good. But they are in alpha, so hopefully it's something that'll improve.
It's a paid subscription website and has done very well as a one-man-army project. Its success hasn't compromised its virtues of being lightweight and no-nonsense (unlike Delicious).
If SourceHut could do the same for Git that would be great.
You can sign-in for free while it is alpha and try it. Everything works very well except the account data export that is not still enabled. I have found it very practical and fast, much better than the typical github+travis combination.
I've had to deal with reconciling a divergent tree; I've seen code that does not appear in `git show x` for any x in `show show --full-history`, and discovered that `git show XXXX` is different from `git diff XXXX^..XXXX`. I'm sure a fanboy will be along to tell me that a commit is just a monoid in the category of endofunctors and I just need to run `git-vent-branch --relieve-mimic-subtree --stub-indict-file`, but I'd rather not.
I use GitHub to get work done, either on my projects or on others. I do not expect GitHub to innately provide me a degree of fun. That's the job of the projects, not of GitHub itself.
Zoom exited the early adopter phase this past pandemic. It promptly was given significant attention, reasons were found to declare it "uncool", and Jitsi was elevated as the next "cool" replacement.
This article confirms that GitHub is now exiting the early adopter phase. Significant attention is being paid to it, reasons are being found to declare it "uncool" — but, no replacement has yet been elevated as the next "cool" replacement for it.
What will GitHub's replacement "cool" service be?