I don’t even understand why people like GitHub so much, its source management sucks.
It’s not that complicated… people use it because everyone has an account there and so your project gets more visibility (and your profile too, for those who plan to flex it when they look for the next job) and more contributions. Even a lot of projects that aren’t on github have some sort of mirror there for visibility.
Suppose you wanna contribute to gnu grep (or whatever)… do you happen to know off the top of your head where the source repo and bug tracker are? And do you know what’s the procedure to submit your patch?
If you are a company doing closed source, I agree that I don’t see why you would choose github over the myriad alternatives (including the self hosted ones).
Look for ways to do things separately and you will find much better tools
That’s a great way to spend your resources developing yet-another-source-forge-thingie instead of whatever your actual project/product is supposed to be :)
But you don’t have to develop anything. There are plenty of ready-made excellent tools you can just drop-in. The main fallacy is that what Github does is actually useful, or that the pieces it integrates are useful. 90% of Github is subpar for any given purpose. Consider all the possible types of software being developed and all the different release flows and support/issue flows, how could they possibly be shoehorned into a one-size-fits-all? Yet people try their damnest to do exactly that.
A, B, C are three distinct, orthogonal topics that can and should be handled separately. There’s no logical reason to shape any of them after the other. They have to work together, sure, but the design considerations of one must not affect the others.
I interpreted your “look for ways to do things separately” as “look for separate tools that do the various things” (and you have to integrate), but I see now that you meant “look for ways to do things differently”. My bad.
I used gerrit and zuul a while back at a place that really didn’t want to use GitHub. It worked pretty well but it took a lot of care and maintenance to keep it all ticking along for a bunch of us.
It has a few features I loved that GitHub took years to catch up to. Not sure there’s a moral to this story.
It’s not that complicated… people use it because everyone has an account there and so your project gets more visibility (and your profile too, for those who plan to flex it when they look for the next job) and more contributions. Even a lot of projects that aren’t on github have some sort of mirror there for visibility.
Suppose you wanna contribute to gnu grep (or whatever)… do you happen to know off the top of your head where the source repo and bug tracker are? And do you know what’s the procedure to submit your patch?
If you are a company doing closed source, I agree that I don’t see why you would choose github over the myriad alternatives (including the self hosted ones).
That’s a great way to spend your resources developing yet-another-source-forge-thingie instead of whatever your actual project/product is supposed to be :)
But you don’t have to develop anything. There are plenty of ready-made excellent tools you can just drop-in. The main fallacy is that what Github does is actually useful, or that the pieces it integrates are useful. 90% of Github is subpar for any given purpose. Consider all the possible types of software being developed and all the different release flows and support/issue flows, how could they possibly be shoehorned into a one-size-fits-all? Yet people try their damnest to do exactly that.
To do software development you need (A) issue tracking, (B) a clear release flow, and © a deploy mechanism that’s easy to use. A is a drop-in tool with lots of alternatives, B is unrestricted since Git is very flexible in this regard, and C is typically included with any cloud infrastructure, unless you’re doing on premise in which case there are also drop-in tools.
A, B, C are three distinct, orthogonal topics that can and should be handled separately. There’s no logical reason to shape any of them after the other. They have to work together, sure, but the design considerations of one must not affect the others.
I interpreted your “look for ways to do things separately” as “look for separate tools that do the various things” (and you have to integrate), but I see now that you meant “look for ways to do things differently”. My bad.
I used gerrit and zuul a while back at a place that really didn’t want to use GitHub. It worked pretty well but it took a lot of care and maintenance to keep it all ticking along for a bunch of us.
It has a few features I loved that GitHub took years to catch up to. Not sure there’s a moral to this story.