Not too shocking, unfortunately, from discussion when the acquisition was annoucned (https://news.ycombinator.com/item?id=18978251), we knew that this was the kind of private equity firm that makes money by buying products with existing revenue streams, and then _not_ investing in them.
(And the corollary, laying off staff you don't need if you're not going to be investing in it, obviously helps your profit margin).
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.
Agree 100%. Free CI really did provide a massive boost to collaborative open source projects.
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.
I called it. The money men have praises Idera for their new and innovative approach to software development. Also know has fixed cost devlopement to the lowest bider.
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.
This is not a investment. It is a tool for leverage. The goal is not to grow the company it's to get as many contracts as they can and lower the ebita. Once they do this they will take out huge loans for the next company to destroy.
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.
> This is not a investment. It is a tool for leverage. The goal is not to grow the company it's to get as many contracts as they can and lower the ebita. Once they don't his they will take out huge loans for the next company to destroy.
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.
It sounds like a new spin on 1980s-style corporate raiding? Pillaging a company then moving on, leaving behind the carcass. I can't see how this behavior helps us as a society, it's legal but unethical.
I don't know if it's good or bad, but we like to think that vultures fill a niche, make ecosystems richer.
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 these vultures tend to swoop in while the company is still alive and kicking. Everybody expects their company to do amazing in 3 to 5 years and if does not they kick it to the curb.
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.
If it was that alive and kicking founders wouldn't have sold it off to the vultures. :/
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'd like to see a real discussion among the readership of this news site about the kind of companies people want to build. Do you want to create a great place to work and grow that builds value that scales smoothly, or a unicorn that makes VCs, Private Equity, and the douchebag CEO you hired from Cisco rich and you without a job? If the answer is b, that is fine, but technical founders and employees should have their minds and eyes open about how it works.
What do you do when the idea that made you start a new company 8 years ago, made you get up every morning, doesn't do it for you now, and all of your equity is tied up in your old idea?
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.
You joke, but when have you ever heard of a software company calling their product complete, firing most of their developers, and moving to maintenance mode? Building a product and making money by selling it is somewhat of a novelty in the hypergrowth VC world of software.
As a developer this obviously sucks but this seems to be pretty efficient from a high level view. If all the low hanging fruit is done and all future development is just adding features with continually diminishing returns, it makes sense to just go into maintenance mode, extract your profits, and let your developers go work on something else
And, then, after years have passed and the hardware it's running on starts failing, developers have to scramble to update components to a version that's actually supported.
By that time the money is already made from those for who it's cheaper to stay than moving away ... so you can buy the next company with a dying product, milk their customers and move on.
I bet we could find tons of other private equity examples. It's how they do. When they aren't firing most staff to then try to re-sell the company instead.
I agree about calling a product complete. MS Office and Windows were probably pretty complete in the early 2000s. But instead of firing the devs it would be nice if they put them to work on something new.
That's what they've done for the Aurea/Update CRM and they are trying to do it with Qlik. Sencha is a great example of where they buy a company, fire devs, and then hope and pray they can continue with the same revenue due to client inertia.
In the blog about the private equity acquisition, the CTO says "With the support from our new partners, we will be able to invest in expanding and improving our core product"
I wonder if he believed that, even as he wrote it?
It's complete BS, but for some reason C* people often don't understand how dumb this is, but for them it might mean a big payday so they don't care. The inherent knowledge walks out the door with the engineers, and all that is left is code and no knowledge. Hire cheap devs and before you realize it it becomes a write-off for the acquirer. Everyone wins except the people who worked hard to build it in the first place.
My cynical side and bad experiences have taught me if the new guys are saying it it might be true. If the old owner is saying it, it might as well be a lie because they can't back it up even if they think they're being honest.
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.
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
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.
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.
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.
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.
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.
> 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.
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.
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.
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.
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.
I hope no one minds a quick plug... sourcehut has a build service with a comparible UX to Travis CI, but more powerful in some respects. https://sourcehut.org Get in touch if you want some tips on moving from Travis to builds.sr.ht.
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.
It's not ala-carte. You pay your subscription fee and get unlimited access to all features. If you start to use more resources than is reasonable, I'll shoot you an email and talk about it. It doesn't sound like you would, though.
Well, during the alpha it's free, but you're right that it will eventually require payment. But the incentives are better this way anyway: if it were free then in a few years we could very well be having this conversation in the wake of layoffs at sourcehut following an aquisition. Sourcehut isn't based on the VC grow-until-you-burst model. If you pay for your account, you can be confident it's sustainable and aligned with your interests.
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.
Honestly I'm astonished at the speed with which this happened, given the recency of their acquisition. Seems amazingly cynical of their new parent company.
I would guess that this strategy would be more effective in an industry where the people with the most influence over vendor selection were not seeing this story at the top of all their news feeds.
There was a time when I wanted to use Travis CI but the pricing was too much. Then, CircleCI came along with a free plan, and when the time came to upgrade, we did it so easily since we’re already invested in the platform.
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.
CircleCI is also a superior product, especially CircleCI 2.0. Their Docker integration is top notch, and there are lots of ways to optimize build performance.
Most (?) developers can't even buy a mouse without prior permission.
"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.
And making it free, at least initially, for businesses removes the requirement of having to have a conversation about it or get permission. It's the same way Dropbox gained so much traction (arguably, the first to execute this model).
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.
I've been using travis Enterprise for over two years and what has kept that going has been the amazing support and development team at Travis who have always helped us during an emergency, been very responsive and informative in all our interactions. They are the reasons I have backlogged the project to migrate.
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.
I would recommend considering GitLab CI as well. I started moving some projects over there a few months back and I've been quite happy with it. The transition from Travis CI was pretty smooth. There are some differences in concepts (cache vs artifacts), but the GitLab CI documentation is pretty good.
Plus you can run it all locally with a couple of docker containers (gitlab-ce/gitlab-ee & gitlab-runner).
You should have already been doing this, before the acquisition. It felt like Travis had been on auto-pilot for a long time. It was painfully obvious to me and our team that Circle is actually hungry and constantly innovating and wanted our business. We moved one project to Circle, waited a bit, and then moved everything away from Travis. Don't regret it one bit.
I kept putting of switching from Travis to Circle-CI in one of my open source projects, But when I did get around to it the whole thing went pretty smoothly and easily and I regret not doing it earlier.
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.
Hah agreed :) We had one project that kept breaking in Travis, and we started to realize that starting over in Circle was easier than the troubleshooting / feedback loop in Travis.
I got stuck as soon as I found out CircleCI didn't scrub secrets from the log automatically like TravisCI. I know, I know, but we have a pretty hefty legacy OSS build in place and that's a lot to shore up before go time haha. Need to check back on that feature request...
I've worked somewhere where it was taking so much effort getting Jenkins set up. In the long run it would be better, but I couldn't wait months and months for the stuff that I got working in maybe 20 minutes with a .travis.yml file.
Disappointing to see this happen. I like devops stuff that covers 80% of your need with 20% of the work.
Really? Bullshit titles (which are already not taken seriously in tech circles) are the reason? This seems to be a bit of an asinine assumption given their success and track-record.
It's not about whimsy being "too much". It's that it conveys an unprofessional and immature image, which may result in people taking their business elsewhere.
I too looked at this page a few years back. And I was not impressed. I wouldn't find it appropriate for e.g. a medical company which does "serious" stuff to very rigourous levels of quality controlled design and verification. But equally I don't think it's appropriate for this company either. Maybe a games company which is focussed upon making things which are fun. I think we will have to agree to disagree on its appropriateness.
As for judging people based on their actions and output. It took them over two and a half years to update their images for Ubuntu 16.04. Where are the Ubuntu 18.04 images? It's nearly a year already. Maybe I'd have a better impression if they could maintain their service to an acceptable standard. As it is, this lack of timeliness was a huge letdown, and cause endless frustration and setbacks on the teams I worked on who depended upon these images being up to date and not full of incompatible language and tool versions.
This is nonsense; Travis employees are the polar opposite of "codebros".
Lighthearted team profiles are absolutely not an insight into the employees' "mentality". If anything, your insinuations are in extremely bad faith and you should know better than to slander people you don't know, especially those whose livelihoods got snatched away.
Very lazy and bad stereotyping, 0/10 points, try again.
So why bother having a team page then? If want to contact someone in sales, do I go for the mermaid or the avocado? A technical question, the hot dog or the tortilla?
So the only purpose of that page seems to be to prove that the company employs actual humans? As opposed to all those AI run software companies?
I know, I'll use the contacts page. If there was any. Which there isn't. Just a twitter handle at the footer, which would be insane to conduct any sort of serious business, and a generic support email.
I have nothing, absolutely nothing against any of the Travis employees or the company. I never used their product. But in all honesty this does strike me as unprofessional.
This weird judginess in this thread is something I hate about tech culture.
I don't know what a codebro is, but I'd be wary of casting too many stones in a thread where you are going out of your way to shit on something as inconsequential as some lighthearted job titles on an /about page and suggesting that it's a symptom of their failure.
Reminds me of observing my friend's kids' social group where everything was "literally cringe." I was walking with them in the mall and they spent the whole time gossiping about how "cringe" everything was. Didn't have a single interesting conversation the whole time because they were too busy judging everyone for superficial things.
What's interesting to me is that the comments here think they're revealing something about the victim of their judgments, painting this whole bizarre narrative about them, when they're really exposing themselves as, frankly, insufferable.
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.