Brief summary

Open source has become an important model for building interest and trust in a software project. But there’s no one-size-fits-all approach to open source. In this episode our podcasters explore different ways to approach open source and examine whether end-of-life has to mean obsolescence.

Podcast transcript

Alexey Boas:

Hello, and welcome to the Thoughtworks Technology Podcast. My name is Alexey. I'm the head of technology for Thoughtworks Brazil, and I will be one of your hosts this time together with Rebecca Parsons. Hello, Rebecca.

Rebecca Parsons:

Hello Alexey. Hello everybody. I am Rebecca Parsons. I am the Chief Technology Officer for Thoughtworks and one of your co-hosts. And today we are joined by three guests, and we're going to be talking about various aspects and approaches to open source. So first, I'd like you all to introduce yourself. Brandon, why don't you start?

Brandon Byars:

Hi, Brandon Byars, been at Thoughtworks about 12 years now. Currently playing a couple of roles, the market tech director for the central market in North America, and while our head of tech for North America is on sabbatical, I'm filling in for her role as well.

Rebecca Parsons:

Duck, you want to go next?

Aravind SV:

Sure. Hi, I'm Aravind or Duck. I'm a consultant at Thoughtworks with a development background, working with C#, Java, Ruby projects in the insurance, healthcare and retail domains over the years. Over the last few years, I've been a product manager for GoCD, an open source continuous delivery server started at Thoughtworks.

Rebecca Parsons:

And Zabil.

Zabil Cheriya Maliackal:

Yeah. Hi, I'm Zabil. I've been with Thoughtworks for roughly 12 years. During that time, I've been a developer working on a lot of projects, but most of my time actually has been spent working on a lot of open source projects, like the openMRS, Rapid FTR, GoCD, And now I'm the product manager for Gauge and Tyco.

Alexey Boas:

Okay. And then perhaps all three of you could talk a little bit about the projects you're going to talk about and mention them the projects you have experiments with. So Duck, why don't you start talking or telling us a little bit about GoCD?

Aravind SV:

Sure. GoCD, As I mentioned, is an open source, continuous delivery server started at Thoughtworks way back. I think it started its life being called Cruise in the 2007, 2008 timeframe. Before that we were responsible for multiple tools in the continuous integration space, but it felt like there was something missing in the next step of that journey.

So GoCD or Cruise started off by being the initial implementation of the idea of delivery pipelines and what would later be called continuous delivery. In fact, Jez Humble, one of the core authors of the continuous delivery book was the first product manager of of GoCD. And at that time it was a closed source commercial product, but around 2013 or so, we were quite frustrated that continuous delivery wasn't as widespread as it could be. So we open source GoCD around early 2014 and came up with a few optional commercial components.

It gained a lot of interest at that time, and as the technology landscape changed, it improved to work closely with containers, containers schedulers, image registries, infrastructure as code, pipelines as code, et cetera. And at the end of 2019, we decided to open source the previously commercial components as well. And currently it is completely open source and we're working with the community and a small steering committee to help decide its future direction and find a neutral home where it can continue to thrive.

Alexey Boas:

Thanks so much sounds exciting. You get to hear more about the history and experiences with GoCD. Zabil, can you tell us a little bit about Gauge and Tyco?

Zabil Cheriya Maliackal:

We started Gauge and Tyco around about 2014, and by starting it had the solid foundation of our reputation and testing. If you've been following talk books we know that there's a lot of popular testing frameworks that came out of Thoughtworks, like Selenium, WebDriver, even in a widely used tools like Mockito. So Gauge and Tyco came out of of these experiences, out of our testing experiences. And it does a test automation framework where Gauge is a test runner, is a framework for writing your specifications that mock down and then running them. Tyco is a browser driver, you can use it to automate browsers and we've been working on it for the past six years.

Alexey Boas:

Okay. Thank you so much Zabil. And how about Mountebank, Brandon?

Brandon Byars:

Sure. So it started about the same timeline as what Zabil was talking about. I think I wrote it over the Christmas holiday in 2013 and released it the following January. And it is, there's a joke that my ex-colleague Pete Hodgson used to say that every Thoughtworks dev has to cut their teeth building their own mocking framework, and so at the time that's kind of how I viewed it. I've subsequently learned that there was a name for the class of tool that Mountebank is, it's called service virtualization, which is taking the stubbing idea and extending across process boundaries so that you can stub out HTTP calls, it's quite common. Actually the very first use case of Mountebank was a binary Java serialization format that was crossed boundaries using an ESP at the time. And so it allowed us to stub out some downstream dependencies in a way that allowed us to test all kinds of interesting scenarios that were otherwise difficult to test.

Alexey Boas:

Cool. And I guess it's going to be interesting to talk about the different perspectives and different evolutions of these open source projects. So we have two that were heavily company sponsored, and one that is more personally driven. And Brendan, while we were discussing this previously, I remember you talking about three prongs for open source projects, product, architecture, and communities, the third one. How does that go? Did I remember that correctly?

Brandon Byars:

Yeah, that's right. And that's one of the learnings I've had approaching seven years now of maintaining this product. Like a lot of developers, once upon a time I was quite passionate about trying something out in code and then Git Hub was a useful platform to host the code and I would call that open source, but when I released Mountebank and then people started using it, I realized there's obviously a lot more to maintaining an open source product than just getting code into a public repository.

And so those three lenses are kind of how I think about it nowadays. There's a, I think, a very significant product lens. In fact, that's been probably my biggest learning, maintaining open sources is how to think about support, how to think about your releases and documentation adoption, how to do the appropriate handholding, how to think about features that fit inside the product and those that should not fit inside the product.

Architecture and community kind of go hand and glove. The developer community obviously contributes to open source. That's one of the benefits you can crowdsource some feature in bug development, but it has to fit both within the product lens in terms of, is this the right feature for the product, and the architectural lens in terms of, does this fit the evolveability of the product over time? Is this a natural extension point? Do I need to refactor something that I had in the past so that it could be a natural extension point in the future? And balancing those three prongs, and Mountebank is one maintainer, it's just me, so I tend to be leads across all three of those, but in theory, I can as product scale, you could think about different roles for those different activities.

Alexey Boas:

Yeah. That's interesting. We see some open source projects that evolve as a product more organically, adding features and things like that. And Duck, you talked a little bit about GoCD. That seems to have a very strong product driver based on an opinion that grew in the community and Thoughtworks itself, about how to do continuous delivery and et cetera. And then it builds on that. Is that right?

Aravind SV:

Yeah. That's right. It definitely started out with a strong vision. Even though it was company sponsored, I guess that happened a little later, it started off as an idea from what we had learned from working on projects across Thoughtworks, across the world within Thoughtworks. But it definitely had that core vision about continuous delivery, about delivery pipelines, and so on.

But as Brandon was saying, it's hard to stay with it when people in the community want to do things with it that you don't necessarily want to be a part of the code base of your product. It's really hard. It was really hard, at least for me, to say no at the beginning. I felt that often that leaves a bad impression with potential contributors, turning them away, that goes to the other prong that Brandon mentioned around community. But if you allow everything, then people contribute changes that don't reflect the vision of the project and then go away leaving whoever is left to maintain that going forward I felt.

A middle ground I've seen as a well thought out extension mechanism, which can go somewhere and giving freedom to people while keeping the code of the project simple and clean. And I think we ended up doing that with GoCD. Once we learned that lesson, the hard way I suppose. One thing about division is, for example, GoCD and Thoughtworks in general actually have been very vocal about the benefits of trans based development for instance, over long lived feature branches.

And this was a sticking point that we refuse to consider branch based work flows for a long time, telling people that they shouldn't be doing it, but eventually the direction of software development, I feel, moved towards branches, especially in the form of pull request, which are just branches hidden behind a different name, and that affected GoCD. It didn't make sense to hold onto that vision after a while. And that vision had to evolve to encompass the branches as well. We still tried to keep it out as a core code base, into that extension mechanism that I mentioned, but that meant we couldn't integrate very well with branches, maybe as well as some other tools in the space could. So it's a balancing act. It's definitely a challenge.

Alexey Boas:

Thanks. And how about Gauge and Tyco, Zabil? My understanding is that it's also founded on strong opinions on how testing should be done, and does it drive its vision from that?

Zabil Cheriya Maliackal:

Yeah, it does. If you look at the fetus of a product and our testing approach also, many of the times, one point of contention was flaky test. And so people just wanted a feature to keep rerunning test until they past. And while we always wanted to focus on features where tests are independent, they are not flaky, when they are flaky there is a problem that you need to solve. So you can say most of the features has been opinionated. And if you look at my role, and probably Duck's role, via product managers and before these open source projects, so we had a large part in our roles to spend a lot of time defining the vision, reaching out to users, and also bridging between our opinions as a company, on how practices should be going into these products. So yes, it is a bit different from other open source projects.

Alexey Boas:

And Duck, you did mention saying no. So one question I'd like to ask you all three is, once you open source a project, and you open it up to the community, does that increased productivity, all of a sudden you start moving much faster? Or does it become more difficult because things get pulled in different directions?

Brandon Byars:

It is more difficult, is the simple answer. But sometimes that friction in Mountebank's case has driven the product forward and directions that I wouldn't have naturally taken it there because I just didn't have the perspective that needed. It's more difficult because of probably two primary reasons, that sort of conflict with those other two pillars outside of the community. One, people have ideas of things that solve their point problem that they're facing, but that don't fit the general product direction of Mountebank. So Mountebank, the core of it, is meant to be protocol agnostic, and somebody has a specific problem for example, and web, and they want to change the core in a way that doesn't even think about the other protocols because they don't use them. And that doesn't fit the product vision that I have to have to work with on this. Duck was saying you have to sometimes learn how to say no artfully.

The second reason it's complicated is because there's just obviously a wide variability to the quality of community submissions from the pull requests. Some people who submit pull requests are full time developers, most of them haven't spent the time to understand the design of the code because why would they, they're just trying to contribute to open source would be good citizens. And so a lot of times you have to spend quite a bit more time with the back and forth to help them understand the constraints, and then to think about the documentation and the appropriate tests, then you would have had you the feature yourself.

But the good part of that is you get, in Mountebank's case for sure, I have seen it extend in directions that I never would have thought of and that I'm quite happy to have taken the product in those directions in terms of scale, in terms of supportability concerns. And so I've gotten a lot more visibility to how the community uses it and what that definitely informs product direction through opening up the community, but it does mean there's quite a bit of maintenance on the human side.

Aravind SV:

Thinking back, I had the opportunity to see GoCD from when it was commercial to when it went open source, and I would say the open source part of it has definitely been much more work. Maybe it is about growing that community, right? That is an aspect that you don't have to worry too much about if you're closed source. Apart from all the things that Brandon already mentioned.

But one thing that I would like to add to what Brendan was saying around contributions is that, I think I mentioned this earlier, sometimes there are contributors who come and stay with you for a long time, and they're the ones who tend to overtime understand the architecture and what you're trying to do, and we were lucky enough to have some of those. And they're the ones who ended up contributing major chunks to the code base.

And there are others who are very thoughtful about it, but they're more of a drive by, like add a feature and go away, kind of people. So there are different kinds of people who try to contribute and managing that becomes a challenge in itself. There was a point where, as Brandon was saying, it might be easier to write it ourselves. So there was a point where I would say yes, and then rewrite whatever they had written. And that was not sustainable, not the right thing to do, and wasn't really teaching people about what we were looking to do around the vision of the product. So that stopped pretty quickly.

Zabil Cheriya Maliackal:

I'd like to add something on this from the Gauge and Tyco's perspective because when we started Gauge, we moved from a product that was closed sourced to a completely new product, which was written from scratch. And one thing we did from day one is build Gauge in a way that it's as extensible as possible, so it has a plugin architecture it uses. It deliberately built it in a core and a plugin model.

So what we've seen over time is a lot of people use the plugin model without having to touch the code so much, and they are able to extend it in a way and use it in their own alignment without interacting or asking us to add many of the features into the code. This already used a lot of note in managing the community.

Brandon Byars:

Yeah. And if I can just tag on to that. So I did not originally create Mountebank in sort of that micro kernel plugin architecture, quite intentionally. I tried to keep it monolithic because I thought that would simplify adoption. There were fewer knobs to spin when you start to use it. And over time, and it's funny listening to both Zabil and Duck talk, over time I've had to make it a microkernel architecture so that you could, and people have, create their own LDAP extension, their own GRPC extension, because that was the only way that I could be really thoughtful about the contributions I manage, and the contributions that don't need to come through me, but the still evolve the overall ecosystem. So I think there's an interesting pattern that you're seeing across all three of these products towards that architecture.

Alexey Boas:

Yeah. That's very interesting indeed. And I imagine it would allow... It would go back to the other two prongs. It would be much easier to manage community, and at the same time it could allow for, experimentation of features and things like that, that are not integrated into the core, but are just extensions that people might choose to use or not to use them.

And how about the evolution of these products, their life cycle? So we have a couple of different examples here. So Duck, you did mention the history of GoCD moving from company sponsored to community sponsored. I guess the same thing is happening to Gauge and Tyco. We also see products that start being built by one person and then get adopted by a company and things like that. So other some patterns of life cycles and some lessons learned from that?

Brandon Byars:

Yeah. I think those are some of the patterns. So, GoCD and Gauge, obviously they have some corporate sponsorship. With Thoughtworks you see open source products like Kubernetes that have sponsorship with Google, React. And that's a common pattern and that's a good one because when you use those tools, you know the company behind them, and there's still a community outside that company, but you have at least some sense of longterm commitment to the product.

The challenge with a lot of products that start individually is there's a less certain path to long-term ownership because it's very easy for me, for example, maintainer of an open sourced product to say, "Well, I've heard of the life priorities at the moment. So what are my exit ramps for that?" A lot of successful ones start off open source and then become corporate managed over time, and either through a foundation, or through a commercialization of the product. So you see that with some of the SmartBear products like SoapUI and Cucumber. And I think that's a very successful path. I think all long running open source products that are individually managed need to think about what is sustainability beyond my time mean? Either I can set up a bit of a federated governance model and there's enough community contribution that works, or I need to think about how do I get it into a foundation? I need to think about how do I commercialize this in some respects?

And that's really interesting because when I started open source a long time ago, I never would have thought of the path from open source to commercialization as success because it's a bit more of the militant Richard Stallman view of the world. But now when you think about ownership, that's really the only thing that you can't rely on a single person, multiplied by a factor of 10 or a hundred or a thousand, with the number of open source products who use enterprise as a solid foundation or even as architecture. So I think if you need to think about the different pathways and life cycles of open source products.

Rebecca Parsons:

Well and thinking about to that life cycle, when you consider the rate of technological change, some of these products can become obsolete. And I think this is a discussion that I've had an internally where it's like, "We can't stop supporting that, but that isn't the way we would do it anymore." It no longer makes sense and so I do think one of the decision points in the life ycle of an open source product is what does end of life look like? And product vendors go through very considered processes around how do I bring end of life to a product? And if we're going to advocate thinking about the product aspect of an open source project that end of life is something that does need to be considered. When is this no longer relevant?

Aravind SV:

Yeah. And I think that's, end of life, is not necessarily as bad as we make it out to be. We seem to think of it as... And it happens all the time. Maybe we need to think about an architect for that when we use things, but we tend to see it as a major event. Of course there are Google like believers known for end of lifeing products left and right, all the time that people are used to, so that's something that they have a challenge with.

But I see, for example, Dex, if you know, D-E-X. They have a... I mean, cannot have made it an end of life where this was set in stone. And that is the implementation which you can refer to forever. That is a different kind of end of life that he envisioned for that.

I see people seeing activity as an indicator for stability and life of a project, but in the case of Dex and other things like that, it's not necessarily true. I've seen this more in the list speaker system where something is stable and it was doing one thing well, and they've just left it, and it doesn't mean it's dead. It's just doing what it did well. Maybe it'll become obsolete like Rebecca said, but that doesn't mean inactivity doesn't need to mean end of life.

Zabil Cheriya Maliackal:

Plus I like to add on what is mentioned over here in the example of Dex and the products that we are doing also. Most of the products that we started is to validate an idea and show that it's possible. For example, GoCD, it was around continuous delivery and the ideas that just we're talking about, the ideas we had implemented over here.

When we started Gauge and Tyco. And Tyco also, it was about smart selectors being able to select without using X spot and all of that. And these ideas are the more important point of the project. They get adopted by other projects and they make their rate or influence other projects or the industry in the practices. And possibly that is the measure of success that we are looking at in this projects.

Alexey Boas:

Yeah. I think that's a very interesting perspective in my view, it goes back to Brandon's community prong because when you build a solution to a problem and you have a community around that, a community not just of users, but of people implementing that solution and learning, you're influencing and changing the industry in a different way with the project.

So open source projects can make an impact that's different than closed products because of that. So if people are learning about a solution and then the industry moves or the problem moves in a different direction, technology moves in a different direction, but people have learned about that and can build on top of that. So that creates an impact and shares a solution that can be learned and evolved. And that doesn't mean end of life. It just means that it has evolved into something completely different, but these invisible effects, any visible impacts, I think they're much more pervasive when talking about open source.

Brandon Byars:

Yeah. I think it's easy to point to a number of examples where that's true. So you look at Spring, who has been very successful in the Java world, but if you remember when Spring came out, that there was a bit of an explosion of these inversion of control open source projects that were roughly came out a little bit before, roughly the same time as Spring. Most of them didn't survive, but that was a big paradigm shift for the industry thinking in terms of these modular components and pro Joe's, instead of these big J2EE components that added some friction to the development process.

Duck's talking about GoCD, but Thoughtworks first continuous integration tool was called Cruise Control, which is where the Cruise name came from. Nobody uses Cruise Control anymore but it changed the industry in terms of how we think about automated tooling for continuous integration and bled into what became continuous delivery. A lot of the testing tools, Selenium I was mentioned earlier, when some of the earliest Thought workers were thinking about this tool for testing browser applications, the name really, as I understand it, this predated my time of Thoughtworks, but the name really this idea of Selenium is your antidote to Mercury, which was one of the big commercial testing products that operate under a different paradigm. And there wasn't a developer friendly. It wasn't as easy to integrate into integration pipeline.

And the fact that none of the, Selenium is still around, but the fact that Cruise Control and some of those early inversion of control containers aren't around is okay because they changed the way that we think about software and the paradigms have been adopted by other tooling, both open source and commercial. We built an open source tool in the mobile space called Calatrava, which allowed some portability between mobile platforms in a way that was pretty unique at the time. And while that product isn't around anymore, some of the ideas that have been adopted and this getting Xamarin is a commercial tool, that adopted similar ideas in that space.

That's one of the great things about open sources, it gives you a lightweight way of throwing ideas out into the ecosystem. And even if your tool adoption isn't what moves the needle on that, that the idea is behind it oftentimes do.

Rebecca Parsons:

It is unfortunately though, very difficult to measure impact. You've got this nice number adoption, or if it's a commercial product, dollars in revenue, but trying to measure impact and quantify impact is difficult. But it is something that we have intentionally fostered this notion that what's important to us, when we're looking at these ideas, is the impact that it does have on the industry.

Brandon Byars:

Yeah. And even adoptions not easy to measure and open source oftentimes as well. I don't know that any of them, unless you commercialize it, it's not necessarily true that any of those numbers are easy to measure, but impact is certainly the hardest.

Rebecca Parsons:

Yes. Adoption does not equal downloads.

Alexey Boas:

Okay. And I guess this takes us to the end of the episode then. It was a great conversation and awesome to have you all with us. Thank you very much for joining.

And if you have any feedback for us, don't hesitate to reach out or to leave a rating or comments on your preferred platform. Thank you so much for listening. Bye everyone.