Welcome to another episode of Talking Tech! This time, we had an excellent interview with HeroDevs, a software development company known for offering “life after end-of-life” services for open-source software. During the interview, their CEO Aaron Frost and CTO David Welch walked us through their growth journey processes and shared valuable insights into their approach to managing remote teams and fostering a unique team culture.

The Story of HeroDevs

Nika Jorjoliani (Head of Engineering): Your business model is very interesting; what was the main idea behind it, and how did it come to fruition?

Aaron Frost: HeroDevs originated in the Angular community. In addition to starting HeroDevs, I was also one of the founders of the biggest Angular conference in the world, which is called ng-conf. Through that conference, my career really grew, and everyone eventually knew me as the “Angular guy.”

I started HeroDevs to consult on Angular, React, and Vue. When Google killed AngularJS (or Angular 1x), I was really mad and frustrated. I decided to support AngularJS after the end of life as a way to get more consulting clients. Once we began offering this extended support, it quickly became clear that our extended support was far more crucial to many customers than our consulting services.

We had an incredible 2021 – our top-line sales increased tenfold in just one year. After that, we doubled our sales again in 2022. But it required us to have a lot of faith. We spent a few million dollars of our own cash before seeing a penny. So, it was a scary transition, but we made it.

Nika: What was the moment when you knew this would work and those millions weren’t spent in vain?

Aaron: One day, I had a phone call with Akamai. Then I hung up and took a phone call with Amazon, NASA and the NBA. And I think that’s the day when I knew we did it. For a small company like ours, it felt like a dream come true.

Shermadin Osadze (Business Development Manager): What is your product, and what does it do?

David Welch: First of all, it’s an actual tangible product – we find, fix and maintain the software. It comes with three guarantees: first, it ensures the security of the software. Second, it guarantees compatibility, which means that if the browser changes from underneath you and the API goes away, we will make sure that we fix it and keep it going. Then the third is its commercial grade, which is equipped with SLAs and commercial guarantees.

We serve a diverse customer base, including large enterprises operating in regulated environments and small startup teams with a minimal amount of developers. We have to ensure these clients don’t use unsupported software. So, we assist them in achieving a compliance check, making the tangible product compatible and defensible.

So, technically, our vision is to set higher standards in compliance and security and cut out all the noise. If something goes wrong, we are the people who will take on the risk of it. We’ll provide a fix within specified timelines and make the whole process practical and viable.

Aaron: I’m going to describe our product from a different perspective, perhaps more from a marketing angle.

In the open-source world, there’s a hidden cost we don’t often talk about. While it’s free to start with, there’s an ongoing effort to keep up with the authors. Developers know this, but it’s not always clear to management. We represent an option for them – a way to lag a bit behind but still remain compliant with all the laws of the land.

Around 60-70% of the community migrates on time, but a small percentage can’t. It’s this minority that requires extended support, an Enterprise offering for that specific software. And that’s where we become really important.

As open source reaches its end of life, it goes into long-term support mode. Our team extends this support forever with an Enterprise SLA, and we provide it for as long as they need it. That’s why we branded our support services as “never-ending support.”

In addition to all that, we have a pretty large consulting team that helps these same customers do migrations and development work. But our main focus is on our never-ending support products.

Partnerships and Team Culture

Shermadin: You have partnerships with both the Angular and the Vue teams, and I’m pretty curious: how does this partnership work? How do you establish and maintain them?

Aaron: Every partnership is a little different, but usually, how we do it is that we hire one of the original authors of the software onto our team. For example, we have maintainers from Vue V2 who are part of our team. Misko, the creator of Angular, is also on our team in a limited capacity. Our team also includes one of the most significant contributors to AngularJS and original team members from Bootstrap, Drupal, and many other major open-source libraries.

I think it’s really difficult to build something that many fantastic engineers want to join. Probably the most important thing we do is build a team that has an amazing culture.

Shermadin: Technical minds working on these technologies probably need to innovate constantly. How do you manage to do that? Is the answer culture, or are there other factors at play?

Aaron: Safety is the number one word I use with my team. My identity around protecting people goes back to my childhood experiences. Also, as an organizer of ng-conf, I’ve learned that traumatic events can occur, and I have a duty to try as hard as possible to prevent it from happening. So, my main focus is to make sure everyone feels safe while they’re at HeroDevs. This mentality is really part of my DNA. I also focus on maintaining a good work-life balance for the team and looking out for their mental well-being. This approach helps us attract and keep top talent on the team.

Managing Remote Teams

Shermadin: How did remote work impact your team’s overall efficiency? And how do you manage remote teams that are globally distributed?

Aaron: Ensuring remote team efficiency involves two main elements: having the right leaders and using the right tools. It all starts with creating a culture where everyone’s safe and where mistakes are viewed as opportunities for improvement. This involves consistent coaching and keeping a shared vision as a team, even though it can be challenging sometimes.

For example, it’s very expensive and logistically challenging to take all your employees off of work and have a week together where you do a mini-conference. But that’s what we do. This is how you create culture in a remote team. In April, we’re taking the entire team to Cancun for our annual meeting-of-the-minds.

Remote work allows for more time at home with our families, but the downside is missing out on the enjoyment of your team members. So you have to create opportunities for people to enjoy one another.

For example,  we have a free lunch on Friday, where each team member uses a company credit card to buy their lunch, and we gather online to chat and have lunch together. 

Twice a month, we have a game hour where everyone gets online to play games for an hour. We also organize fun competitions on Slack, such as sharing the funniest childhood photo. Everyone votes, and the winner receives a $500 prize. 

The other important factor in managing remote teams is using the right tools. An example of such an invaluable tool is called Gather. It allows your team to have an online office and to have the same type of communication you did when you were at work together.

It’s an 8-bit game-looking environment where every character has their own desk. If anyone walks into my desk area, their camera turns on, and if I want to talk to them, my camera turns on. You don’t have to create a calendar invite to have a conversation. You can just meet without any friction. And so, an online office space is probably our most important tool. You can see everyone else’s calendar in the room, ongoing conversations, and even a conference room setting.

Having an online virtual environment absolutely revolutionized the level of connection that we had as a team. So, using tools like Gather,  HubSpot, and Slack helps your team to have frictionless communication.

Sharing Technical Insights

Nika: What were the primary challenges you faced when initially started supporting AngularJS, and how did these evolve as you incorporated more technologies into your list of supported products? Could you highlight any particularly complex issues you managed to resolve?

David: We were early adopters of AngularJS, which started back in 2009 when the project was first released. A year later, we faced significant challenges due to the impending discontinuation of AngularJS. We had to deal with outdated tools like Bower for managing dependencies and were limited to using build systems such as Jenkins. The initial stages were particularly difficult, including reviving old project branches that had complex build systems. Each of these experiences helped prepare us to provide never-ending support for AngularJS. These challenges helped prepare us to maintain AngularJS for anyone who needed ongoing support.

The maintenance phase brought its own set of challenges, especially when handling security vulnerabilities or incompatibilities. To stay ahead, we run our tests nightly or weekly, depending on the level of what it is, both against the current and the future browsers.

By adopting this approach, we ensure that if, for example, Chrome Canary presents any issues for AngularJS, we have a six-week buffer to prevent these problems from impacting our production or main builds, where customers could face issues. This strategy allows us to identify and address potential problems well before they affect our users. Our goal is to maintain smooth operations for everyone and minimize the risk of unexpected disruptions.

We emphasize maintaining consistency in the size, shape, interfaces, and compatibility of our products. They are designed to be directly replaceable to minimize disruptions for our users. We conduct thorough testing whenever a product update is necessary to confirm that it maintains the expected user experience. If there are any deviations, we provide detailed documentation, training, and support to guide our customers through these changes so that they can navigate any updates smoothly.

Nika: What is your delivery process like? Especially in terms of how you manage and execute projects. What is your approach?

David: We follow the Software Development Lifecycle (SDLC) in our operations. We don’t have a fixed release cadence for our products. We avoid introducing new features regularly as they may introduce risks. Our focus is to provide a guarantee to users that they can continue running with what they have. Our clients value stability and security above all other things. We aim to be the perfect partner by focusing 100% of our efforts on providing those two values to them.

Our release cadence is not based on feature demands or external priorities; we prioritize that internally and manage it within the team. We work more in a Sprint fashion than a pure Kanban; we are a small team and have the flexibility to adapt as needed. We have test environments, integration tests, cross-product test environments and things to check. So there’s a lot of quality engineering where we spend our time.

We deliver all our code to customers so they can see exactly what’s happening. But how we work through those things is very much a private thing. We’ve got to manage the risk of the responsibility for everybody. And we do that with a certain level of caution here.

Nika: Do you manage the quality of the product by using automated test suites and testing it on different environments, or do you have any other method to make sure that the quality of the software doesn’t fall back?

Aaron: We follow the same practices as the original authors to ensure security and quality. This includes running tests and security scans. We use a proprietary toolchain to scan the code for security vulnerabilities and identify potential issues. Once a potential issue is identified, then it’s up to us to reproduce it. Then, we can fix it, retest it, and release the fix to our clients. That’s the quick answer for what we do.

David: The purpose of our product teams is to ship secure software to end customers. Our goal is to ship this piece of the engine that everybody depends on and keep it running indefinitely.

Nika: When working with older components, do you modify or refactor them or focus solely on addressing specific issues? Could you describe your strategy and the extent of changes you usually make to the existing code?

Aaron: We make the least amount of changes possible when dealing with older components. When we’re talking to our customers, we promise them that we won’t refactor but only make adjustments for security and compatibility. That’s what our customers want. Enterprise managers don’t want the floor to move underneath them. And that’s what we offer.

When you look at what we’re doing, it’s consistent with the practices of the original authors.

Nika: What led you to make Vue.js one of the main focuses?

Aaron: Our customers are very large enterprises and institutions, including Amazon, Microsoft, GE, and the American government. When customers buy AngularJS support, for example, they often ask if we also support Vue2. So we decided to provide Vue2 support based on our current customers’ requirements. That’s one of the reasons why we looked into it. Our connections with Evan, the creator of Vue.js, also played a part in this decision. So, that’s why our business side decided to focus on the Vue community. We’re also looking at doing the same thing with the Next.js Community as well.

Future Plans

Nika: So what’s next? What are your plans for the future?

Aaron: In 2024, the most popular version of Drupal (Drupal 7) is reaching its end of life. We’re officially partnered with the Drupal Association, sponsoring the project, and they’re educating the community about what we do in case they need continued support. So we’re staring down the barrel of another humongous end-of-life moment in December this year. 

We’ve launched never-ending support support for Bootstrap 3 and 4, the most popular versions of Bootstrap. They’re very difficult to upgrade because Bootstrap 5 no longer uses jQuery. We’re also launching jQuery support. 

We’re getting into our first operating system and planning to extend support for the now end-of-life CentOS. We’re also trying to finalize conversations on the Spring framework with one of the team members, as well as focus on the PHP ecosphere a bit more.

Our stretch goal for 2024 is to release a beta program of supporting everything on NPM for enterprise and government customers. This is going to be extremely difficult and expensive, but that’s where we’re currently focused. So we’ve got a lot coming up in 2024 and 2025. After supporting everything on NPM, our goals only get crazier from there. If the moon has a moon, we’re aiming for the moon’s moon.