5 ms·

Because people absolutely refuse to learn from history. The gravity of the situation is the same as it always is: OSS projects have created a hard dependency o

by blihp 6y ago

Because people absolutely refuse to learn from history. The gravity of the situation is the same as it always is: OSS projects have created a hard dependency on a commercial 3rd party service because it was given to them for free. Free service is now going away and they're screwed because they have no plan 'B'. The issue isn't that they haven't gotten off of it already, it's that they likely never should have gotten on it to begin with. Seriously, with all the OSS projects building workflows on Travis CI / Slack / GitHub (I'm talking about the non-git parts of it like issue management) / etc how do they think this will all end? Even YouTube is sending signals that the free ride (for unmonetizable content) will likely end. OSS projects should not have dependencies on non-OSS infrastructure unless they are prepared for this eventuality. This has happened, in various forms, to most 'free as in beer' services given enough time. Companies typically provide the service as some combination of crush the competition / building goodwill / altruism / the prospect of eventual conversion of some small fraction of OSS projects to a paid version. The reasons tend to vary (in this case, new ownership) but eventually the bottom line tends to win out. Often you won't be given much time to transition when the free ride ends.

progval 6y ago
> OSS projects should not have dependencies on non-OSS infrastructure unless they are prepared for this eventuality. I don't think that's the issue. Large parts of Travis are open sourc, but no one uses it because they are too complex to set up; and there are better self-hosted solutions than Travis. Travis was attractive, because it was free hosting, not just software. And worked with just a few clicks
- outsomnia 6y ago
  If it's not selfhosted, or it's not FOSS, it's not under your control and can go away any time. It's certainly easy to get into these lassaiz-faire ad-hoc remote free solutions, it's harder to maintain your own CI, but if quality and consistency is important, it's not that hard.
takluyver 6y ago
What was the better option? Should small OSS projects have lived without CI for the last few years? Or should everyone who publishes an OSS project set up and maintain a self-hosted CI service for it? Either option would be a massive drag on OSS development. It doesn't actually matter much for this if you use an OSS CI service like Gitlab: the hosted service is still dependent on the generosity/marketing of the company hosting it, and switching to self-hosting is much more effort than porting config from one CI service to another.
- brodock 6y ago
  migrating GitLab from "cloud" to self-hosted is as easy as importing the project. You can even import in batch and things will "just work". https://docs.gitlab.com/ee/user/project/import/gitlab_com.html#project-importing-from-gitlabcom-to-your-private-gitlab-instance https://docs.gitlab.com/ee/user/project/import/gitlab_com.ht... hosting CI yourself is equally simple. The worker can be installed with few commands, and with a few extra you can configure autoscalling: https://docs.gitlab.com/runner/install/ https://docs.gitlab.com/runner/install/
  - takluyver 6y ago
    I'm talking about setting up the infrastructure before you get to either of those points. I don't want CI running on my laptop - especially for an open project where anyone can submit a merge request - and I don't have a server to use for it, let alone a private Gitlab instance ready to import projects to.
- jrochkind1 6y ago
  So, my experience as an OSS developer is indeed that I wouldn't have switched to CI in the first place if Travis hadn't existed. I had heard of CI testing, and sure it sounded good, but we had all been making due without it, and I didn't have time (and certainly the projects didn't have money) to set it up. But travis made it so damn easy and free to turn on, there was no reason not to try it. Once tried, there was no going back, we would never want to do otherwise. Travis really defined this market and opened up CI testing to entire communities. We owe them (employees, former management) a debt of gratitude for that. But then we come to depend upon it for sure. Which they had no obligation to supply it forever, and perhaps it wasn't even sustainable business to do so. So now what? Well, now we move over to other free options like Github Actions which fortunately exist. But is it dangerous to depend on the largesse of for-profit companies? FOR SURE. Is it, at this point, hard to figure out how to do otherwise? FOR SURE. So, what could we do instead? In my dream world, we'd have a non-profit collaborative project to provide CI to open source on an ability-to-pay basis. Is that likely? I dunno, raising money for open source is already a problem. And it's a hard project. As long as there are companies providing it to us for free, it's definitely less likely.

by blihp 6y ago

progval 6y ago

> OSS projects should not have dependencies on non-OSS infrastructure unless they are prepared for this eventuality. I don't think that's the issue. Large parts of Travis are open sourc, but no one uses it because they are too complex to set up; and there are better self-hosted solutions than Travis. Travis was attractive, because it was free hosting, not just software. And worked with just a few clicks

outsomnia 6y ago
If it's not selfhosted, or it's not FOSS, it's not under your control and can go away any time. It's certainly easy to get into these lassaiz-faire ad-hoc remote free solutions, it's harder to maintain your own CI, but if quality and consistency is important, it's not that hard.

takluyver 6y ago

What was the better option? Should small OSS projects have lived without CI for the last few years? Or should everyone who publishes an OSS project set up and maintain a self-hosted CI service for it? Either option would be a massive drag on OSS development. It doesn't actually matter much for this if you use an OSS CI service like Gitlab: the hosted service is still dependent on the generosity/marketing of the company hosting it, and switching to self-hosting is much more effort than porting config from one CI service to another.

brodock 6y ago
migrating GitLab from "cloud" to self-hosted is as easy as importing the project. You can even import in batch and things will "just work". https://docs.gitlab.com/ee/user/project/import/gitlab_com.html#project-importing-from-gitlabcom-to-your-private-gitlab-instance https://docs.gitlab.com/ee/user/project/import/gitlab_com.ht... hosting CI yourself is equally simple. The worker can be installed with few commands, and with a few extra you can configure autoscalling: https://docs.gitlab.com/runner/install/ https://docs.gitlab.com/runner/install/
- takluyver 6y ago
  I'm talking about setting up the infrastructure before you get to either of those points. I don't want CI running on my laptop - especially for an open project where anyone can submit a merge request - and I don't have a server to use for it, let alone a private Gitlab instance ready to import projects to.
jrochkind1 6y ago
So, my experience as an OSS developer is indeed that I wouldn't have switched to CI in the first place if Travis hadn't existed. I had heard of CI testing, and sure it sounded good, but we had all been making due without it, and I didn't have time (and certainly the projects didn't have money) to set it up. But travis made it so damn easy and free to turn on, there was no reason not to try it. Once tried, there was no going back, we would never want to do otherwise. Travis really defined this market and opened up CI testing to entire communities. We owe them (employees, former management) a debt of gratitude for that. But then we come to depend upon it for sure. Which they had no obligation to supply it forever, and perhaps it wasn't even sustainable business to do so. So now what? Well, now we move over to other free options like Github Actions which fortunately exist. But is it dangerous to depend on the largesse of for-profit companies? FOR SURE. Is it, at this point, hard to figure out how to do otherwise? FOR SURE. So, what could we do instead? In my dream world, we'd have a non-profit collaborative project to provide CI to open source on an ability-to-pay basis. Is that likely? I dunno, raising money for open source is already a problem. And it's a hard project. As long as there are companies providing it to us for free, it's definitely less likely.