Dependabot is joining GitHub(dependabot.com)
dependabot.com
Dependabot is joining GitHub
https://dependabot.com/blog/hello-github/
46 comments
If the increase in homogenization comes from everyone keeping their packages up to date and secure, I'm going to see that as a net win for the community.
Sure. I think what he's saying is, even if the built-in version of Dependabot is good, it's really hard for another startup to come along and make the the next Dependabot 2, that does things even better. Without that threat of competition, Github's implementation may stagnate. I haven't seen any indication of stagnation from the Github team yet though.
I understand and agree that that is what parent is saying.
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.
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.
I would argue that GitHub has appeared substantially less stagnant _since_ the acquisition than the year or so beforehand.
(Edited to correct a typo)
(Edited to correct a typo)
Yes. They were about to have their enterprise lunch eaten by GitLab
Wouldn't that stagnation be exactly what prompts another startup to come along and make the next Dependabot 2?
I don't see vendor lock-in as a net win for anyone but the vendor.
They might see GitLab as a threat (GitLab itself aims to be an all-in-one platform) and are taking steps to up their game.
So instead of having the choice between a neutral platform and an all-in-one solution, we get two all-in-one solutions cloning each other.
There's a name for this kind of market failure, but I can't remember it.
There's a name for this kind of market failure, but I can't remember it.
> But: all the built-in tools will have an inherent advantage over third party solutions. This inevitably leads to increased lock-in and homogenization.
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.
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.
This just gives an easier option.
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'.
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'.
If you view Github as just a Git (and occasionally static site) hosting service, then there's not lock-in whatsover; you can always move to somewhere like Gitlab or host your own. But the point is: Github isn't just a Git website anymore; it creates a community around it. Right now the reason why people aren't easily moving out of Github is because by moving to somewhere else, they have to risk getting less views, less recognition, and less pull requests for their libraries. Also, if you were a Sponsor in Github and earning $30000 a month and then had disagreements with Github's policies and want to get out, you now have to risk shaving off all your sponsors to switch to a different service like Liberapay. Maybe some of your passionate existing patrons will go towards the extra effort to switch alongside you, but the reality is: most won't.
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.
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.
If you were a Sponsor in Liberapay and earning $30000 a month and then had disagreements with Liberapay's policies and want to get out, you now have to risk shaving off all your sponsors to switch to a different service like GitHub. Maybe some of your passionate existing patrons will go towards the extra effort to switch alongside you, but the reality is: most won't.
This isn't an argument against GitHub or LiberaPay. This is an argument against being locked in to any financial intermediary.
This isn't an argument against GitHub or LiberaPay. This is an argument against being locked in to any financial intermediary.
Possibly a slight difference though in that GitHub isn't _just_ a financial intermediary; with all the other functionality on offer, it may be a lot easier to find something to disagree with/dislike
It disincentivizes GitHub from maintaining feature parity of the API for integrators with what is available through UI.
Yes, if they announce the new "integrated" dependabot version will continue to only use public APIs, that would be a major positive statement about the "openness" of Microsoft GitHub. Otherwise buying major tools and integrate them looks scary.
For some reason centralization is such a loaded term these days, and I wonder why.
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.
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.
Centralizing to Github means giving them a monopoly. Privately owned monopolies are a horrible idea.
When I built GitButler[0], I did so fully expecting that GitHub might come one day and kill it by providing a better integrated solution. That's the natural order of things, ultimately, whoever owns the platform, controls it and 3rd parties can't do much. That's also the reason I've shifted my attention more towards open platforms lately.
[0] https://www.gitbutler.com
[0] https://www.gitbutler.com
I would agree if this came with changes that would block out newcomers. But third parties can still build just as they always have been.
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.
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.
[deleted]
> 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 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.
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.
GitLab first nudged everyone in this direction I think.
This is a special case of the general trend that increasing quality is a barrier to entry. Even with a bit of competition, it's just harder to compete as complexity goes up and users have higher expectations. For example see the top-selling movies or games.
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.
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.
it was never "neutral" or "open" in any real sense;
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
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
Curious about the side effects of this.
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.
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.
This is absolutely a thing. I've ignored something until heroku let me know it's on such an old platform version, it'll keep running but not restart. So I've given it an update recently.
I gave one of my projects a bit of an update after someone mentioned a part of it was no longer working. I enjoy those kinds of reminders as it reminds me some people still use it.
I think existing repo will get nothing but maybe something will be enabled by default for new repo
Which is good for open source repos
I enabled Dependabot for my main OS projects just now
I enabled Dependabot for my main OS projects just now
Massive congrats to the team! Well deserved, Dependabot is an awesome tool!
Thanks! We have plans to make it even more awesome from within GitHub :-)
Microsoft really is growing GitHub. I can't say I'm not pleasantly surprised.
The bush in my backyard is growing too, similar to the PHP API surface circa PHP5, not every growth is a good thing. I am very cautious of what is to become of Github in a couple of years.
Did GitHub just activate this without confirmation or notification? I'm suddenly receiving PR's on my repo's from dependabot without ever activating this tool.
Edit: looks like they defaulted to enable "Automated security fixes" on the Security > Alerts tab.
Edit: looks like they defaulted to enable "Automated security fixes" on the Security > Alerts tab.
Congrats to the Dependabot team!
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!
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!
Congrats guys! For anyone interested, here's an interview on how Dependabot started:
https://www.indiehackers.com/interview/living-off-our-saving...
Congratulations! We're very happy with our Dependabot use and hope it helps the community
Anyone else remember that whitespace bot that spammed everyone's repos? Last thing we need are more bots clogging our code shitters.
Can anyone recommend a tool similar to Dependabot that works with bitbucket?
Massive congrats to the team - what a great and well deserved outcome :)
congrats!
Huge congrats to Dependabot team! If you're starting a new project in Python (+ others), having Dependabot + CircleCI (or something equivalent) + Strong test coverage will save you hundreds of hours (eventually).
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.
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.
Thanks!
That makes so much sense! A more secure open source world, a better product for our close projects and two amazing tools merging. Love it!
Dependabot, you did well, build a fantastic tool, now join the rocketship and kick ass!
Dependabot, you did well, build a fantastic tool, now join the rocketship and kick ass!
> A more secure open source world
A world built on proprietary services is not an open source world.
A world built on proprietary services is not an open source world.
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.