4 ms·

From the tweet [0] it seems there is going to be a huge tech debt. I don't know how Idera is planning to expand upon the acquisition after letting go people lik

From the tweet [0] it seems there is going to be a huge tech debt. I don't know how Idera is planning to expand upon the acquisition after letting go people like this. > Some know the skinny on dozens of different open source projects and ecosystems, others understand run time and dep mgmt for like 17 languages and even more tooling, and automated image mastering to handle it all. > Others are rewriting what it means to manage communities in this era. They had to garden github issue repos with 1000s of tickets and find the patterns, and know a wide swath of the open source community in ways most people will never get to again [0] https://mobile.twitter.com/carmatrocity/status/1098538650525188096 https://mobile.twitter.com/carmatrocity/status/1098538650525...

lostapathy 8y ago
To (sadly) be fair, Travis has already been struggling mightily with tech debt the last few years. There have been a lot of issues surface and re-surface that sure seem like they shouldn't be a big deal. For example, setting a build to use ruby 2.4 is supposed to run the latest ruby 2.4.x, but would frequently build against ancient, unsupported rubies for a while, before being silently fixed.
- mikepurvis 8y ago
  They've also been very slow to ship updated machine images— Ubuntu 14.04 wasn't available until late 2015, and 16.04 wasn't until Nov 2018: https://blog.travis-ci.com/2015-10-14-opening-up-ubuntu-trusty-beta https://blog.travis-ci.com/2015-10-14-opening-up-ubuntu-trus... https://blog.travis-ci.com/2018-11-08-xenial-release https://blog.travis-ci.com/2018-11-08-xenial-release The extremely long lag combined with some communications from Travis developers on related Github issues strongly implied that shipping these was a highly manual process, not just a matter of updating a few Packer configs and calling it a day. I'm not arguing that it's trivial, but it should have been a week or two of effort at most. Now, lots of their userbase could be covered by using docker environments, or by the natural isolation supplied by the language platform (virtualenv, rbenv, etc), but at the end of the day, it's frustrating if your CI environment is drifting away from what developers are actually using themselves.
  - rleigh 8y ago
    This was concerning for several years now. Who knows when 18.04 will make an appearance. 2021? Never? I appreciate what they were trying to do with their multiple versions of every language in their stock images. But, in practice there were numerous compatibility problems. If you look at the C++ tickets, you can see how utterly unusable their offering was for this language. From the outside, it looks like they painted themselves into a corner and are mired in technical debt. Quite why it took two and half years to support 16.04 is a question I'd be very interested to know more about. One solution is to use custom docker images. But that negates any advantages Travis might have had. I can run a docker image anywhere. So when I switched over to GitLab, I use GitLab CI with docker images and custom runners to do fairly comprehensive platform coverage. Something Travis will never do. They also made a questionable business decision in tying themselves to GitHub. Why no integrations with BitBucket, GitLab, Jenkins, and all the other hosting and automation solutions out there? I had to write Travis off purely because of its lack of availability. The above problems were also an issue, but if it doesn't integrate with your hosting solution, it's a non-starter.
  - lostapathy 8y ago
    On top of how late "new stuff" often was, I never understood why they kept out of date, unsupported stuff running for so long - especially for free, open source projects. http://rubies.travis-ci.org/ http://rubies.travis-ci.org/ They support ruby 1.8.7 and ree. ree went unsupported in 2013 (https://www.infoq.com/news/2012/02/ruby-eee-eol https://www.infoq.com/news/2012/02/ruby-eee-eol) If anything, I feel like they are actually doing the open source community a disservice by supporting build environments that are no longer supported by the upstream community. They legitimize testing against ancient, unsupported environments, rather than moving forward deliberately to stay on a supported stack. I understand there is a burden on updating software, but given all the trouble we have with breaches in old software, we need to bias the world toward staying on stacks that get security updates rather than sitting stagnant.
- LiamPa 8y ago
  I still don’t know how to test against py3.7...
dtech 8y ago
From the previous discussion, it seems like Idera's mode of operation is stopping active development on the product, and maintaining it more or less as-is as long as there are people using it. Then it's not necessary to reduce tech debt.
- bluedino 8y ago
  This same pattern happens with 'dying' ERP software. The users aren't going anywwhere, unless you for ce them. It takes years and millions of dollars to switch ERP platoforms. Buy the company for...what a year or two (or even less) worth of contracts equals. Fire all the developers. Keep a skeleton support staff. Fire sales/marketing. In-house everything else. Then just keep getting paid by customners until they all finally go away.
  - wil421 8y ago
    You forgot the last step. Once you finally collapse, sell all source code and licenses to use the software to the last remaining customers.
  - gm3dmo 8y ago
    But Travis is the choice of well weapon DevOps people, they will be able to swap out to a new CI in 10 seconds flat. Hell, a dingbat like me could probably do it in a day. An ERP system, not so much.
    - pietroalbini 8y ago
      Depends on the complexity of your CI. Big projects might take days to migrate, or even more.
    - tomc1985 8y ago
      Last company I was at, our ERP transition took years
  - rleigh 8y ago
    Swapping out Travis for something else takes a few minutes. If you have a lot of repositories and very complicated scripts, it might take a day or so. But ultimately, the lock-in for CI solutions is minimal. The effort to migrate is very small. Over the last few years, I've transitioned projects between Jenkins, Travis, AppVeyor, CircleCI, GitLab and others. In most cases, the logic had mostly been factored out in to shell scripts and batch files. Telling one CI system to set up the build/test environment and run that script is pretty much the same as any other. And this might be the reason why this layoff has happened. What future did Travis have as a business? What was its growth potential? How many paying customers did it have? When everything you offer is done better, often for free, by your competitors and customers can easily set up their own self-hosted replacement if they choose, I'm a bit skeptical that the business was worth that much in the first place.
jrochkind1 8y ago
> I don't know how Idera is planning to expand upon the acquisition... I would guess they are not, which is consistent with how they seem to have treated past acquisitions. I am not sure if a developer-focused integration-dependent tool like CI can continue to consistently bring in a revenue stream without getting much development attention... but I think they're going to find out.

lostapathy 8y ago

To (sadly) be fair, Travis has already been struggling mightily with tech debt the last few years. There have been a lot of issues surface and re-surface that sure seem like they shouldn't be a big deal. For example, setting a build to use ruby 2.4 is supposed to run the latest ruby 2.4.x, but would frequently build against ancient, unsupported rubies for a while, before being silently fixed.

mikepurvis 8y ago
They've also been very slow to ship updated machine images— Ubuntu 14.04 wasn't available until late 2015, and 16.04 wasn't until Nov 2018: https://blog.travis-ci.com/2015-10-14-opening-up-ubuntu-trusty-beta https://blog.travis-ci.com/2015-10-14-opening-up-ubuntu-trus... https://blog.travis-ci.com/2018-11-08-xenial-release https://blog.travis-ci.com/2018-11-08-xenial-release The extremely long lag combined with some communications from Travis developers on related Github issues strongly implied that shipping these was a highly manual process, not just a matter of updating a few Packer configs and calling it a day. I'm not arguing that it's trivial, but it should have been a week or two of effort at most. Now, lots of their userbase could be covered by using docker environments, or by the natural isolation supplied by the language platform (virtualenv, rbenv, etc), but at the end of the day, it's frustrating if your CI environment is drifting away from what developers are actually using themselves.
- rleigh 8y ago
  This was concerning for several years now. Who knows when 18.04 will make an appearance. 2021? Never? I appreciate what they were trying to do with their multiple versions of every language in their stock images. But, in practice there were numerous compatibility problems. If you look at the C++ tickets, you can see how utterly unusable their offering was for this language. From the outside, it looks like they painted themselves into a corner and are mired in technical debt. Quite why it took two and half years to support 16.04 is a question I'd be very interested to know more about. One solution is to use custom docker images. But that negates any advantages Travis might have had. I can run a docker image anywhere. So when I switched over to GitLab, I use GitLab CI with docker images and custom runners to do fairly comprehensive platform coverage. Something Travis will never do. They also made a questionable business decision in tying themselves to GitHub. Why no integrations with BitBucket, GitLab, Jenkins, and all the other hosting and automation solutions out there? I had to write Travis off purely because of its lack of availability. The above problems were also an issue, but if it doesn't integrate with your hosting solution, it's a non-starter.
- lostapathy 8y ago
  On top of how late "new stuff" often was, I never understood why they kept out of date, unsupported stuff running for so long - especially for free, open source projects. http://rubies.travis-ci.org/ http://rubies.travis-ci.org/ They support ruby 1.8.7 and ree. ree went unsupported in 2013 (https://www.infoq.com/news/2012/02/ruby-eee-eol https://www.infoq.com/news/2012/02/ruby-eee-eol) If anything, I feel like they are actually doing the open source community a disservice by supporting build environments that are no longer supported by the upstream community. They legitimize testing against ancient, unsupported environments, rather than moving forward deliberately to stay on a supported stack. I understand there is a burden on updating software, but given all the trouble we have with breaches in old software, we need to bias the world toward staying on stacks that get security updates rather than sitting stagnant.
LiamPa 8y ago
I still don’t know how to test against py3.7...

dtech 8y ago

From the previous discussion, it seems like Idera's mode of operation is stopping active development on the product, and maintaining it more or less as-is as long as there are people using it. Then it's not necessary to reduce tech debt.

bluedino 8y ago
This same pattern happens with 'dying' ERP software. The users aren't going anywwhere, unless you for ce them. It takes years and millions of dollars to switch ERP platoforms. Buy the company for...what a year or two (or even less) worth of contracts equals. Fire all the developers. Keep a skeleton support staff. Fire sales/marketing. In-house everything else. Then just keep getting paid by customners until they all finally go away.
- wil421 8y ago
  You forgot the last step. Once you finally collapse, sell all source code and licenses to use the software to the last remaining customers.
- gm3dmo 8y ago
  But Travis is the choice of well weapon DevOps people, they will be able to swap out to a new CI in 10 seconds flat. Hell, a dingbat like me could probably do it in a day. An ERP system, not so much.
  - pietroalbini 8y ago
    Depends on the complexity of your CI. Big projects might take days to migrate, or even more.
  - tomc1985 8y ago
    Last company I was at, our ERP transition took years
- rleigh 8y ago
  Swapping out Travis for something else takes a few minutes. If you have a lot of repositories and very complicated scripts, it might take a day or so. But ultimately, the lock-in for CI solutions is minimal. The effort to migrate is very small. Over the last few years, I've transitioned projects between Jenkins, Travis, AppVeyor, CircleCI, GitLab and others. In most cases, the logic had mostly been factored out in to shell scripts and batch files. Telling one CI system to set up the build/test environment and run that script is pretty much the same as any other. And this might be the reason why this layoff has happened. What future did Travis have as a business? What was its growth potential? How many paying customers did it have? When everything you offer is done better, often for free, by your competitors and customers can easily set up their own self-hosted replacement if they choose, I'm a bit skeptical that the business was worth that much in the first place.

jrochkind1 8y ago

> I don't know how Idera is planning to expand upon the acquisition... I would guess they are not, which is consistent with how they seem to have treated past acquisitions. I am not sure if a developer-focused integration-dependent tool like CI can continue to consistently bring in a revenue stream without getting much development attention... but I think they're going to find out.