Travis CI Is Laying Off Senior Engineer Staff
twitter.com
twitter.com
This is kind of how private equity works.
It is sad, I had really liked travis as a product, I don't expect I will be able to continue to.
Travis is just _so easy_ to set up for my basic ruby gem and Rails app projects (I don't want to spend time on setting up CI, I just want it to be done), as well as free for open source -- none of it's competitors have seemed to give me that when I looked before.
Travis, by offering an absolutely brain-dead setup, and giving it away free to open source, really created a revolution in actually doing CI for open source, at least in ruby. Everyone's doing CI now, when few open source projects were before in ruby. That anyone offers free CI for open source at all is probably due to the need to compete with travis. I wonder if it'll stick around.
As a user, it did a lot to increase software quality: not just catching inadvertent bugs, but also ensuring that there was at least some reproducible way to get the code working, that didn't depend on some implicit configuration of the authors system.
As a maintainer, accepting simple pull requests becomes much easier when you can quickly look over the code and check the CI status, and not have to try it out locally yourself. It was certainly critical to the "social coding" idea behind GitHub.
So thanks to the team that put it together. Even if the product you built doesn't live on in the way you hoped, it has certainly had a lasting impact for the better on the open source world.
If you want stop this type of practice please don't sign multi year contracts. That is stage two. This is where they get their value.
Without the contracts they can't use it as leverage to take out huge debts -- where they get their value from.
If the fed raised the rates this practice would also end.
If you're a founder, you're usually going to cash out for the right price. Everyone has their price. No one wants to grind forever. This isn't a problem if you're profitable enough that you can hold forever (Basecamp).
If you're an investor, you're struggling for returns right now (to your point about interest rates and the Fed). You're going to squeeze whatever you can get your hands on as hard as possible (as an investor myself in real estate and small SaaS companies I've bought, I try very hard to not do this, but you're hedging against a multiple you paid for the asset; you don't want the asset's cashflow to disappear and watch your capital evaporate).
Interest rates rising would help, but so would orgs more tilted towards employee ownership. You have to align incentives. Are you happy with a lifestyle business? (Not derogatory! I'd take a lifestyle business any day over any sort of possible unicorn status) Are your coworkers/shareholders? Would you customers be willing to be shareholders thereby becoming stakeholders? These problems are solvable with corporate structures and governance.
Such a shame to see this happen. Great opportunity for GitLab and their CICD team though.
I don't blame the founders. But at the same time I think if enough of these deals for bad these types of investors will stop their bad practices.
This sort of move not only hurts employees. It hurts those who use the product too. It's a net bad for everybody but a few.
I am still digging into how these things work and how the money gets out. But I would not be surprised if sometime in the future this sort of business engineering would be made illegal.
Look what PE did to solar winds and general dollar. Both had huge piles of cash and were drained and put back on the market for the general public to pay the debt.
All investments are buying cashflow or value appreciation, that is the end goal, regardless of the method. As long as the PE firm involved gets more cash out then they put in, it was a successful investment.
I address how both companies and customers can protect themselves in my comment you replied to. If someone buys a private company, the majority shareholders were willing participants. Better ownership and stakeholder models protect against these outcomes.
No one is going to buy Let's Encrypt. Consider if that model would work for CICD as a service. Start a non-profit, round up the talent, fire up the infrastructure, provision a Stripe account, and build something better. Let's Encrypt secures the web for $3 million/year. Crunchbase and Glassdoor mention Travis CI had ~$1-1.5 million/year in revenue.
Sure, our economies and ecosystem of firms doesn't necessarily have to look like a full out evolutionary war for resources, but .. it sort of does, and it's not going to change any time soon.
So, im that sense if we want stable and nice companies, we have to care for them. Sort of like we do with pandas, rhinos, and so on.
One possibility is doing pledge, using corporate bylaws to try to guarantee some of that niceness. Do it through IT (and startup, and VC and so) communities' wall of fame/shame.
The problem is if you look at all the amazing companies that are doing really well. The majority of them took near 10 years to come to their own. Half the amazing companies in SV if ran buy these PE guys would not exist if they were given to them at year 5 of their life.
There's difference between PE and PE. Look at SoftBank's Vision fund, they want to invest still more than 100B USD (it's already at around a 100), they want to fuel growth of sectors, etc. And then there's "company turnaround management", where the employee count chart gets turned around, and cashflow becomes king.
I don't think I have that kind of stamina. When you cash out there's no guarantee the next person will do a better job than you did.
Buying something that's already been developed and then not developing it further is a 'new and innovative approach to software development'?
New SDK comes out, make it compile, do the necessary refactor. That's it. Minimal team, no real deadlines, just pure throughput.
"Yep. We were terminated by Idera without even our managers knowing."
in wake of travis being acquired last month. https://blog.travis-ci.com/2019-01-23-travis-ci-joins-idera-...
Not sure if thats douchebaggy. I've seen several layoffs like this, where everyone finds out at the same time not by levels.
It also doesn't sound like everyone found out at the same time.
I wonder if he believed that, even as he wrote it?
The irony is that the better the engineering staff was, the better this works out for the firing company.
If some newbies can pick up the code and quickly become productive, that's to the credit to the staff that was fired.
When the new owners figure out what they actually want to do it's easy enough to get rid of the messenger. Either fire them or they leave in a huff.
> 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/1098538650525...
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.
https://blog.travis-ci.com/2015-10-14-opening-up-ubuntu-trus...
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.
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.
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)
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.
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.
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.
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.
I wish I could hire some of the recently unemployed, but I just don't have the budget. If you want me to circulate your resumes in Philly, feel free to email them to me. Best of luck.
Where do I find pricing information? (Was hoping for the standard "Pricing" link).
Does it require a repo hosted on sourehut too, or can the CI be used independently?
I'll see if I can't get public pricing info up later today.
>Does it require a repo hosted on sourehut too, or can the CI be used independently?
You can use the CI independently. Right now there's a GitHub integration and I'm open to adding more :)
Or did you feel that this isn't helpful either?
Also, if anyone has trouble affording an account, please send me an email. I don't want anyone to be left out because they can't afford the subscription fee, we'll sort something out.
They were in it for the flip sure, but there are different models for achieving this. It's not always a chop shop job.
I wish Travis CI they did this from the start since I like their platform and had some open source projects there and again could have easily upgraded. This is where the fremium model would have worked.
"Free" is more convient at work than at home. If I need something at home I just pay. At work ...
Compare the hazzle of getting a Win10 VM up and running compared to a Ubuntu one with licensing issues. A Win10 image is like 3 days away. An Ubuntu 30 min. The slower alternative also happens to cost money.
I've never ran into the issues you're referring to. Microsoft makes it both easy and cheap to obtain development licenses for their software.
You let all of the employees use something for free, come to rely on it, and then all of a sudden it's become entrenched in the workflow/culture/whatever. At that point, it's easier to just pay for the service than to switch.
See Slack.
Keys issues i've seen in our Enterprise install... * Upgrades can go bad, very quickly and very silently. * Build images are out-dated, missing security patches, bloated, and not easily provisioned with custom features to integrate our tools with theirs. * no tooling for docker builds/deployments * long start up time on the build images. * Enterprise documentation (though it's been improved a lot recently)
Best of luck to #travisAlums, I hope you get picked up quickly.
We’re migrating to in-house Jenkins now. Can’t trust third parties to handle critical infra.
I was a big pusher for Travis, but they’ve lost my trust.
I would advice everyone else to migrate off and mitigate their risk.
1.The builds are much faster now. 2. The configuration has virtually no hacks anymore as I'm using Circle-CI own docker images (including browsers). 3. And the UI/UX is superior as well.
Plus you can run it all locally with a couple of docker containers (gitlab-ce/gitlab-ee & gitlab-runner).
Disappointing to see this happen. I like devops stuff that covers 80% of your need with 20% of the work.
Not sure what the people were doing but this seems typical for a Ruby project.