Made all the more silly by the fact that it's Git. You could just host it yourself for five bucks a month and that's probably overpaying.
Ah, but GitHub isn't selling git hosting. It's a social network that also does git. That's the cake that Microsoft bought, not the UI and API frosting.
> ForgeFed is an upcoming federation protocol for enabling interoperability between version control services. It’s built as an extension to the ActivityPub protocol, allowing users of any ForgeFed-compliant service to interact with the repositories hosted on other instances.
The value GitHub provides is far from unique in anyway, but let’s not pretend it’s trivial. Especially for an open source project already struggling to get contributors to their main code base, even more so for any ops work.
Drugs, alcohol and sugar all fit this description very neatly.
local> ssh user@example.com
user@example> git init --bare $DIR
user@example> exit
local> git clone user@example.com:$DIR
I'm with you in camp baffled.
I compare it to using gmail as your professional email. It's a bad idea; even if it never bites you, because the cost is so little and the harm is so great if it ever screws up.
Except I can see why average joe user might not think about it, and I don't think developers have that excuse. You should know and understand that tech is risky enough. Same reason there was no excuse for the kik zero padding debacle. The fact that a LOT of people did a lazy dumb thing doesn't make it not dumb or lazy.
Of course you could do all of these things with enough work. But why would the average developer want to? Do you really think most developers care so much about Microsoft owning GitHub?
They use this for access:
(somewhat ironicaly code hosted on github. Not sure its still being updated..)
we currently don't use it, just because its on the same network as our site.. though because its git and it replicates the repo everywhere its less of an issue.
As for myself, I don’t like GitHub UI, which is slow, has low information density, and is generally lollipop-like; and its social media aspect, which often turns the bug tracker into a Twitter equivalent with viral bugs, emojis to cheer and boo people.
So I set up a cgit instance for myself. Patches can be sent over mail as attachments generated with git format-patch (attaching files to mails isn’t hard). Issues can similarly be sent over mail and described in a BUGS file.
That’s sufficient for my single person projects. Probably also for n-person projects for small values of n (let’s say 7). Past that I’d set up a Gerrit instance, which IMO has the best UX of all code review tools available, free or not; and a Redmine for ticket tracking.
There is no situation in which I'd want to do all of the above work for every single repository I setup.
I have hundreds of repositories that I own on GitHub for things like school assignments and personal projects. If I start a weekend project as you describe then the first 4 hours are going to be setting my repository up.
Nobody wants to do this. Just because something is difficult or time consuming doesn't mean that it is good or useful. Doing this once would be a fun learning experience. Doing it more than once is a useless chore.
What the heck are you talking about?
The only work you'd have to do "for every single repository" is the single git command.
Getting a server, managing access and discoverability, setting it up for browser access, setting up backups, those are things you would do once.
If that's a waste of four hours, valid argument, but it's not a waste of four hundred hours. You're grossly exaggerating the cost.
Oh and you didn't mention keeping the server updated but that's probably ten minutes of effort once a month.
> Doing this once would be a fun learning experience. Doing it more than once is a useless chore.
Then there's no problem.
Sure, it might work fine forever, but when it doesn't, you're really screwed and you could have avoided that in a relatively simple way. Reminds me of seatbelts and fire extinguishers.
It's good to have a backup plan, but it's convenient to keep using it for now.
Even Ignoring the value and the features, Employers don't ask for your git link, they ask for your GitHub account. And since most projects are on GitHub having all of your projects there tooz makes it easier to see all of your commits, making your profile look more active.
That's without mentioning the ease of discovery and issue reporting since everyone has an account.
Embrace
Extend <-- here
Extinguish
Do you mean copilot? I would not classify that as extending anything. It's just a thing they made.
"Monetizing goodwill" is not an extend.
And the idea of the extend of EEE applying to all of open source at once, the way you could apply to a product or a standard or a protocol, doesn't really make sense.
It's basically Microsoft saying "Here is a thing that looks like it might in some way eventually be a threat to our business model and/or we can make some money off of it -- let's get our hooks in now and see what happens, we have the money to do it."
EEE doesn't need a specific plan but it does need some kind of target standard. Getting into an emerging market, without specific kinds of integration or malfeasance, is just competition.
1. Acquire company for tens of billions.
2. Intentionally ruin own investment.
3. ???
4. PROFIT!
?
1. Acquire company for $7.5bn in stock, so fortunes are joined rather than cash paid
2. Still charge money for it
3. Create an AI product out of the open source bit of it, justifying the price tag, as well as build links to Microsoft dev tools to entice OSS back into the Microsoft ecosystem
4. Maybe profit, but almost certainly not loss
Because too many open source projects rely on it. Projects like crates.io force you to have a github account to use it. Most (neo)vim plugin managers give preferential treatment to github over other forges.
But if you've been watching, literally the only reason they don't hate it now is because they lost the open source v. proprietary battle.