All the recent additions to Github are superficially very nice and convenient features (Actions, package registry, Sponsors, Dependabot).
But they represent a very significant change in mindset. Github is turning from a neutral code hosting platform with a myriad of equally empowered third party integrations into the direction of a "all in one" dev tool and platform.
I understand the internal pressures to do this: increased popularity, added value proposition for customers, more revenue.
But: all the built-in tools will have an inherent advantage over third party solutions. This inevitably leads to increased lock-in and homogenization.
I was very critical of the Microsoft acquisition for similar reasons, and considering the monumental role Github represents for open source today, I am very sceptical of the way things are going.
We might very well regret centralizing everything open source around Github in a few years.
I think it might be worth considering that Dependabot outdid a Github feature to do the exact same thing. Dependabot beat out the in-house Github implementation by being better and having better features. Indeed, Dependabot integrated with Github better!
I understand the concern. There's a very real fear that having Dependabot in-house at Github might mean that something even better never develops. It's very possible that this might come true this time! But I am skeptical, given that it clearly failed to occur previously. I'm not seeing why this time around will be different, but I'm sure that's just a lack of vision on my part.
Plus, well, if Dependabot keeps away all would-be competitors by being so good at what it does that nobody can compete... I consider that a win. My main concern and primary goal is more secure software, not more startups rooted in an ecosystem around Github.
(Edited to correct a typo)
There's a name for this kind of market failure, but I can't remember it.
There's no lock-in, you can continue whatever integrations or pipeline you have now. This just gives an easier option. Them offering Github Pages isn't lock-in to their hosting, but it offers convenience in various scenerios.
These features are a disincentive for users to look for alternatives, which in turn is a disincentive for people to start businesses to provide alternatives, which altogether has a cooling effect on the tooling ecosystem.
That's not to say GitHub shouldn't provide these options. They're useful additions to a great platform. My remark is simply about the economics of a supplier with substantial market share adding a new feature. It has a wider impact that being 'just another option'.
There were lots of promises and hopes for the patron economy (or I would extend this to call it a "distributed economy"), where people can directly give money as reward for their work while avoiding the traditional hierarchical structure of corporations. However, because of the nature of the current society we live in, the ideal version of this economy would never come to fruition. Think of examples such as Patreon, Youtube, and recently Github; they're an enabler for diverse communities, rich subcultures, and innovative ideas, but the users still have to live under the guise of huge capitalistic forces. It seems that the distributed economy still has to live under the current technocratic system (where huge tech corporations have much higher leverage than small companies or non-profit organizations). To see this relationship between users and corporations as either symbiotic or exploitative is up to your choice, but I think the status-quo will stay for quite some time.
This isn't an argument against GitHub or LiberaPay. This is an argument against being locked in to any financial intermediary.
There are things that centralization deals with that decentralized, open solutions seem to neglect. For example, pushing GitHub to become an all-in-one platform reduces fatigue of having to learn multiple, independent third-party apps/platforms. Not everyone wants nor knows how to write glue/infra code, time is essential and there are other problems to solve. I may be ignorant, but is this related to why AWS took off the way it did?
Add to this the potential combinations of integrations that you need to learn. An internet resource may teach you how to do x+y+z, but if you happen to want to use x+r+z then you're out of luck, will probably take you a lot of time to sort that out.
For some amount of time, I don't remember anything similar like GitHub back then when it launched. Correct me if I'm wrong. I think we can't discount the insight Github has opened us up to, leading to other providers like Gitlab and such. I'm not afraid of homogenization and lock-in, I'm afraid of people getting tired of too many things to learn to be productive these days. There's got to be a point where you stop decentralizing, because where does it end?
> all the built-in tools will have an inherent advantage over third party solutions
If the built-in tools are superior and more effective than third-party solutions, is that a bad thing? If not, then we should do our part and advocate/support the better third-party ones than bring ourselves down against e.g. Github just because things have been getting better and we can't let go of our prejudices.
I'm not a GitHub fanboy nor do I abhor decentralization. I just think it always warrants a case-to-case examination, deep thought. When you start making comments such as "_superficially_ very nice and convenient" when e.g. Sponsors is objectively good for the OSS maintainers and bad for absolutely no one, then you've got to be skeptical of how skeptical you are about things.
As a user, I like that new features are now free instead of paid plugins.
I see this more as trying to get to parity with GitLab with a function of more advanced maturity with cloud computing that’s making it cheaper for Github to run more scheduled task type stuff (scanning and alerting workflow).
I think it will be hard for third parties to compete with free, but it’s kind of like with phones added flashlight to the OS. Sucked for the flashlight app makers.
That being said, I think like will be rough for TravisCI and all the web based software PM products as this is an area where GitLab has more features than GitHub and I think they’ll be growing.
I think some of those trying to compete with Github were already trying to compete by providing better 'native' integrations. Say, Gitlab and CI. You can use other CI with Gitlab and Gitlab CI with things other than Gitlab, but it's meant to be a "don't have to decide just works" integration. Gitlab in general seems to be trying to compete by being much more "all in one".
So it's not shocking to see Github trying to stay on top of things by doing similar.
In both cases, there may be something 'natural' about this means of trying to get customers, some reason that many companies begin with "APIs to get third-parties to give our users good tools" and move towards "all in one" -- as the market matures, I think both for the current market leader and challengers. I agree it has some downsides (as well as upsides) for customers, but it seems to be not unique to github.
Open source code somewhat mitigates this: Apple forked KHTML, then Google forked WebKit, and now Microsoft is building on and may someday fork Chromium. But it remains the case that some projects are very hard to do from scratch with professional quality, and even maintaining a fork requires a lot of expertise.
Also, sometimes you can reverse the aesthetic so that some people prefer stuff that's not professional quality, so you get an "indy" market.
at the same time there is no real reason to fear github that I can see - until it starts claiming ownership of your code or inserting spyware into your downloads or something more subtle
Imagine you had an open source project that was just something on the side or you worked on in a different life. And then you see pull requests for updates and decide to fix a bug here or there. And then maybe it prompts you to recommit to it.
If that were to apply to even a tiny percentage across all of Github could have major implications for open source as a whole.
I enabled Dependabot for my main OS projects just now
Edit: looks like they defaulted to enable "Automated security fixes" on the Security > Alerts tab.
I've had the pleasure of reaching out to Dependabot a few times when I've had issues or problems and you guys have always been super responsive and quick to fix any bugs!
Congrats again on joining Github! And excited to see whats next for Dependabot!
Best trick is to make sure your test coverage is strong early (I know this is easier said than done ...), then you can just merge updated requirements without ever worrying.
GitHub has a type of service that would check requirements already, it just never felt as polished as Dependabot. But it goes to show how far a committed team can prioritize over bigger players. IIRC, they still use Heroku, which seems like a lot of discipline in prioritizing the right product features over just building tech stacks in BigCloudProviders.
Dependabot, you did well, build a fantastic tool, now join the rocketship and kick ass!
A world built on proprietary services is not an open source world.