Lee Skillen from Cloudsmith on streamlined software packaging, building startups and the promise of on-premise

We’re chatting with Lee Skillen, Founder and CTO at Cloudsmith, about how his startup solves the complex issue of streamlined software packaging. We also discuss the ups and downs of being an entrepreneur and starting one’s own business.

Watch this Episode on Youtube

Full transcription below.

Darko [00:00:02] Hello and welcome to Semaphore Uncut – a show where we explore cutting edge technologies and meet people behind them. My name is Darko. I’m the co-founder of Semaphore and I’m going to be your host today. With me today I have Lee Skillen. Thanks very much for joining us and please go ahead and introduce yourself.

Lee [00:00:23] So hey everybody my name’s Lee I’m a founder and CTO at Cloudsmith. We’re a startup SaaS in DevOps and package management space.

Darko [00:00:33] OK great. Thanks. If you can maybe spend a bit more time and talk us through the previous experiences before starting Cloudsmith.

Lee [00:00:46] OK so it’s a long and arduous path and I had a lot of different jobs over time. A lot of that time has been spent in startups. I’m obviously addicted to it and I can’t get enough of the problems that finders need to face on a daily basis. You know so I’m predominantly technical. That’s my life and my passion is developing things that other people love to use and help solve real problems for people.

This is my third startup, the first of which was a reasonably successful search engine that ended up in a ball of fire and carcasses, but the second one was within financial technology and it wasn’t quite as successful but it led to Cloudsmith today and in the recent past couple of years I’ve been working on Cloudsmith. I’ve also had a stint within a couple of sort of corporate cultures which is a bit different and certainly a very different dynamic to working in the smaller startups.

Whenever you’re a smaller car cog in a larger machine the dynamics of the other relation and day to day just a different set of problems you know. I’ve probably seen quite a lot of different technologies, a couple of different working styles out there and certainly enough problems to know what I’m trying to solve with the people that are working in these companies today. Kind of my background predominantly was within C and C++ and more system-level type of programming.

Darko [00:02:16] I’m sorry for interrupting. I was doing some research and I saw C++ floating around so I was thinking should I ask about that or not. I’m glad that you brought that up.

Lee [00:02:29] Yeah well I try to avoid it these days to be completely honest. I’m really glad that I mean there’s still a piece of me that is in love with that era of programming but these days in terms of rapid turnaround for the things that we’re doing, the focus, the shift of these days to probably solving problems for people and whenever you’re doing it becomes more “How quickly can we develop something for the people that are out there”.

So people come to us with the problem and tools like the language today like Python and even language’s like Go enables us to of more rapidly develop solutions for them. You know which is why I’m just in love with that, because with today’s exposure DevOps philosophy about being exposed from the source control all the way up to deployment distribution – actually getting your code out there, it’s a very very different world than it was perhaps 10-15 years ago just developing the system-level libraries and you’ll never even see necessarily the customers that are utilizing that, but eventually it will get out there.

Darko [00:03:30] Yeah yeah. That’s interesting. What you mentioned like experiencing both startup culture and dynamics of that and the enterprise where you know it’s just a different set of problems. I think that in this co-founder/startup mode where you’re developing tools for developers -that’s very valuable to have that insight into the pace of things, how they’re moving and what are the processes behind them.

Lee [00:04:02] But I think it’s probably very similar to yourselves at Semaphore that you are indicative of your own customers as well. Because obviously I’m sure you’re following best practices around deployment and build and I’m sure that you’re utilized Semaphore even internally perhaps for the things that you’re doing.

We try to do the same thing at Cloudsmith – when we’re talking to customers there’s a level of empathy there with what they’re trying to do because they’re trying to solve a lot of the same problems. So it enables us to have this here higher level of thinking around “you’re talking exactly the same things and we talked a lot – these are potential solutions”. I think that’s a fantastic dynamic they have with customers and maybe something that you wouldn’t have in other industries or other types of tooling.

If you’re in an accountancy software as a developer maybe you are not necessarily yourself and the content, so whenever you’re talking to the users that actually utilize your product there’s a little bit of disconnect there between those people and you as the engineer for the product. So I love this industry and I love developer tooling specifically for that reason.

Darko [00:05:04] Yeah. Yeah. Well, to be honest, I kind of started forgetting that you know and kind of keeping track of how blessed we are in that sense because… Exactly as you said, when speaking with customers we end up discussing the technology that they’re using and we’re using and what are the advantages, what are the disadvantages and then we make a full circle and come back to speak about the product and how they can solve things.

So maybe you can tell us a bit more about Cloudsmith. I’m really interested in when choosing what to do next – how it came about. What was the driving force behind?

Lee [00:05:54] OK. I mean this is where it links one startup to the next. The previous startup that I had was completely unrelated to the things that we’re doing today. But it was related to being cloud native and with building platforms. So that’s probably about the only thing really in common with what I’m doing today.

One of the things that we were doing around toolchains, building code. We were bespoke building code for different types of financial customers that were out there and one of the big problems we faced is that once we have this product built, how do you actually get it out there and integrate it with people that want to use it. So we said we needed some sort of distribution platform, some sort of packaging technologies in order to do that. This would have been different customers for different types of languages – so we had Python, C++ we had all sorts of binding Java, etc. There had to be something with what we could sort of centralize a lot of this. So we started looking at that time on the different technologies, different packages, and different services to providers and there wasn’t really one that stood out and was able to solve a lot of our problems.

We did probably the thing that I would tell people not to do and that is “write your own solution”.  Don’t do that if you’re in that situation maybe you could look at additional open source projects that are out there perhaps or collaborate with others out there before you build your own thing and at the same time it’s worked out quite well for us.

So we started building packaging technology and at some point of the business basically, we had decided that the thing that we’re doing around the financial technology was going to take a lot of money to commercialize. We decided that actually, we could maybe split off the package management side of things as a separate business. That’s effectively turned us upside down and we became Cloudsmith as we know today and at that time I think we hadn’t realized just how important something like this could be for people and actually in a way it was perhaps accidental.

The more people that we talked to out there and we realized “Hey this actually solves a real problem for the people out there”. We got more excited about that as we got more and more good feedback from the people that are out there that needed this so it’s kind of how we arrived at what Cloudsmith is and why we’re still on this journey.

We’ve got a lot of exciting things that are coming up based on all these conversations that we’re having with people, but predominantly it solving the problem around complexity in people’s stacks and there’s a lot of assets that are floating around – especially in the days where we’re all trying to manage all of those together is not necessarily that simple to do.

There’s absolutely tooling out there that can do it. But whenever you try to centralize all of that especially as you’re scaling your company with multiple teams it gets more difficult to manage that basically at scale. So a service like Cloudsmith is really helping people with the communication and collaboration aspect, centralization, control and security management as well. So it’s kind of how we arrived at that.

Darko [00:08:57] That’s great. Yeah, it’s typical “scratching your own itch” pattern which is just fantastic. I mean for us it’s pretty similar. We were like Rails consultancy getting into BDD/TDD and wanted to ship something fast. There was just not something around that was like easy, easy enough to use to ship stuff. You are not sure if you would recommend people to do that and to do start building things from scratch but you know, some people have to make these mistakes like you and we did so and end up here.

Lee [00:09:45] Absolutely. A lot of people ask me, maybe they’re thinking about breaking out to do something like an entrepreneur and start their own business. Usually, I warned them up front that it looks very glamorous. You get to be your own boss, you get to do what you want to do, you’re the one that’s defining maybe your own destiny. But actually, in reality, it’s very very hard work.

A lot of people maybe don’t appreciate just how much work is involved especially at a founder startup level. You know where you’re spending… I wear a different hat every single day. You would be exactly the same. Some days that’s business and there’s product management. It’s raising the funds, it’s building relationships and partnerships. Then the other day I might spend my entire day locked in a room in the dark writing code and to be honest I love it. I’ve grown to love it even more as time went on but it’s definitely not an easy thing.

Darko [00:10:42] It comes with its own set of challenges and also exciting moments. In the previous episode I was speaking with Jacob from Packet and one thing that we touched upon is that there is that momentum of how often just the whole company changes and it’s sometimes even like three or six month’s period and then you cannot recognize you know how things are structured and organized and what are the leaps that were made. I think that kind of cancels out the hardships that you’re having by that excitement that it’s something new just after a short while.

Lee [00:11:28] Yeah. And it’s especially at the startup stages through your you’re very very involved with absolutely everything and you still feel very… You would take any negative things that happen very personally as well. Even if it is so loose to the thing that you’re doing, which is a great thing too if you’re really passionate about it and the business that really shows to your customers you know.

We’ve had a lot of great feedback and it’s one of the best things about being a founder because we’re so close to the product and we have this conversation. You know people can see the passion and excitement for it and I think that it’s great for both sides.

Darko [00:12:12] It’s an interesting journey. Maybe if he could jump back to the technology side. I think that what you guys are solving is also very interesting for a lot of customers of Semaphore, so maybe you can give us a few tips and experiences from your period at Cloudsmith but also before, generally about managing assets. You mentioned some of those – what are some of the biggest challenges and maybe patterns and anti-patterns that you have seen.

Lee [00:12:46] OK. I mean it varies a lot. Like I said earlier we speak to all of the customers that we have and we try to speak to as many people out there as possible and I think DevOps is one of those fields that you know is so variable. What people are doing at different companies, but we would always recommend when we’re talking to people that if they’re not doing anything around assets and building package management today, they should certainly be looking at it. There’s a couple of ways of looking at it.

If you’re in a system where you’re utilizing, for example, Docker images and Docker is a fantastic ecosystem – it abstracts quite a lot away from the runtime environments and maybe what traditionally would have been package management except  if you’re going directly from GitHub building Docker containers and maybe you’ve lost some of the trails of how things got into those so that you’ve only seen this zero-pain form which is the containers. So what we see with people is that they still do that. That’s fantastic that you can utilize that for simplifying deployment, but we see some of the customers that probably would use package management that they still would build their asset-chains locally as quickly as possible.

Still, package up things like Java integrational libraries for traceability, so all the metadata that’s still associated with packages is still there, still visible that you know who built it and what particular version and all the metadata that’s associated with it. You know exactly where it came from and you know exactly what point in time it was put into the containers. So I think one of the advice would be don’t necessarily discredit artifact management and package management as the thing that isn’t there anymore.

Think about it in terms of levels of controls. If the ultimate goal is building containers and deployment environment maybe there is something – a smaller unit that you could do around smaller feedback cycles, build better packages as quickly as possible, minimize the feedback loop. Build the packages as small as you can and then maybe you’ve restricted the sort of the level of service for them in terms of developers inputting into and then leave the container building for next stage which you would do anyway.

Darko [00:15:11] Yeah it’s very much a question of what levels of abstraction you use to explain these elements, but you could almost say that whenever you are building that to Docker container, you’re kind of provisioning your server. So that’s kind of that part. However the actually the binaries that are going in and the configuration management and so on it is still a separate phase.

Lee [00:15:40] When we’re speaking to a lot of people – the ones that are in the know and once that aren’t, a lot of the time people don’t realize that whenever you’re building containers something still needs to go into and that may or may not be your code directly but a lot of the time you’re building up these is a composite of many different technologies.

You still have system level packages that perhaps you derive from other sources that maybe you’ve built like I said – your assets before they go in and if you are just doing that directly from code you’ve lost the part of that providence, that chain of trust or at least where it comes from and how you got it.

A lot of the people that are utilizing the artifact management they do it because maybe they are, they would be building a lot of sources of sulfur from other places like public registries and public sources of software and maybe they want to isolate themselves from changes in the public repositories so that they wouldn’t pull those assets into their artifact management system and then utilize those internally only. That means that if there are any issues with the upstreams or if there’s any sort of changes whether on purpose or malicious perhaps that they’re somewhat protected from that. So these are kind of the sort of things that people utilize it for.

Darko [00:16:55] What you mention about isolating yourself from open source or packages that are published publicly. That’s an interesting thing that actually burned us a couple of times. Because our platform is around for many years and we just add different versions of Ubuntu just come and go and recently 14.04 was deprecated and it’s no longer receiving updates. Various packages started disappearing, people are pulling them away and so on.

Lee [00:17:42] It can be known certainly if you’re within the Windows realm it’s what’s informally known as dependency hell. You might be forced to upgrade one part and then all of a sudden you’ve got this here a huge amount of dependencies around that need to be updated. So this is really about establishing control over that system and sometimes it’s out of your control and you just have to move on.

For example, if your customers need an environment that’s more up to date, then you’re going to have to obviously try tackle that, but isolate as much as possible is one of the foundational reasons to utilize things like package management.

Another thing that perhaps we hadn’t realized when we first started to do Cloudsmith, is that for us one of the things that we try to deal with is the people that are distributing, that build packages for other people. So this is like the inverse use, instead of you utilizing the software by isolation, this is about people who themselves perhaps are vendors and they want to distribute it around the world.

We help people with that and sometimes that can be public, an open source project – we’d like to get back and provide for free. The thinking is quite common and this sort of field that you promote open source as much as possible because we all use open source technology. But then there’s also the other people that sell software on so they’re looking for a way of being able to distribute and handle things like licensing. So that’s something we try to help people as well, so it’s not just the people that are building for themselves – it’s also about people that are building for others as well. It doesn’t matter what technology you bring. We support a large part of the market already in terms of technology with a couple of other exciting things coming up as well.

Darko [00:19:24] When you touched upon that – I think you mentioned you recently released support for Rust.

Lee [00:19:32] Yep that’s right. That was actually really exciting for us – we’re huge fans of Rust as the programming language. Happened sort of looked at as something that we might potentially start dipping into for our use of the stack where…

You know we’re predominantly Python at the minute, there’s a bit of Go and a few other languages in there as well and occasionally there would be places where you think that this is quite CP-heavy. There might be potential optimization around there. That’s why we’re exploring additional languages as well.

Also we’re looking at the client side as well so sometimes there might be things we can utilize there so we were really excited about this for the language itself and we knew that the support for alternate registries (is what they called it) was coming up and so we were just sort of waiting for that to launch and then we decided “Hey it’s public now, we really should be out there”.

A lot of people are asking for the capability to use it and we just have to be in a position where we were ready to launch with that. It was very very well received. Had a lot of fantastic feedback from the community and we immediately jumped on to be able to talk to people about it. I mean it’s great whenever that happens and we can open up a whole new product that people did not have access to before, so it’s very exciting.

Darko [00:20:47] Rust is one of those languages which, kind of at least as I perceive it, didn’t have a lot of wind in the back, as Go from Google, but the community around it seems to be very active and enthusiastic. I’m excited to hear that people are asking for it. Knowing that you have some of the background from C++ –  you’ve been interested in Rust comes naturally.

Lee [00:21:20] Yeah. We see Rust as C++ but with all the problems fixed, so don’t be too surprised if you see some Rust-flavored Cloudsmith software come about in the future, so we’re very much on board for that.

Darko [00:21:36] Sounds great. From the recent industry events or maybe not that recent – generally the introduction of Docker containers and they’re taking up at scale and now Kubernetes which is kind of the king of deployment and running all those Docker containers. Is there anything that you see very interesting that’s coming up that you are excited about and you’d like to share?

Lee [00:22:13] In terms of the Docker and Kubernetes ecosystem or in relation?

Darko [00:22:15] I kind of thought upon those as those are the major things that happened. So maybe you see something similar happening or maybe smaller, but that you have recognized and are excited about?

Lee [00:22:31] Well it’s something that’s not necessarily on the cards, but one thing that we hear a lot about and this is sort of related to Docker and containerization as a format. People love that in terms of packaging because it really simplifies and brings things together in one format. It’s almost like a universal format for packaging but it’s not quite there.

The way that we see it will go and it’s something that we’re going to try and contribute to as well is the idea of universal packaging as a format and not just a service. So whenever you start to look at all of the different ways that software out there produces its packaging and how does it control version and what sort of metadata do you need in there and how do you establish links with the service that stores it versus where you use it. You start to appreciate the commonality between all of those, so I think what we’ll probably see is a universal way of being able to package software that still maintains all of the information with it necessary to trace it all the way back to its source in terms of source control.

That’s something that we’re having conversations about with potential partners. I think there’s potential excitement around that because that would solve the link between… Trust is a really big thing at the minute, especially with a lot of news around security recently in terms of “How could this have been prevented and what can we do to really change this?”.

At the minute there’s a lot of initiatives that are perhaps bespoke to the different types of technology out there, but I think there really needs to be done something to address that across each of the different types right there. So I think that’s one of the big things that will be coming up in the industry.

Darko [00:24:15] Yeah. And for me trying to understand that. Essentially as an example – we have Ruby gems or we have Node packages and on the other hand, we have a Docker container and so on. So when speaking about this universal registry, you’re essentially saying that regardless of that actual package, some metadata and traceability and security around that could be attached to it and kind of made industry standard hopefully?

Lee [00:24:49] Yeah. It’s like a packaging format for packaging. Someone sort of made a different analogy to me as to what that’s sounded like. I try not to do this too often but it’s a sort of Star Trek reference (because if you haven’t seen it you’ll not know what I’m talking about).

In Star Trek universe everybody is able to speak the same language because they basically solved the problem of translation. There are no languages anymore or at least they’re still there natively but no one knows it because the universal translator means that everybody can speak the same thing. It’s a little bit like that – if you have a universal translation across all the types of software that you have then you don’t need to think about that anymore.

It’s more about “How do I develop something? How do I get it out there?” and that’s it. There’s enough information in there and that you haven’t lost something on the way. In the same way, today, if you’re building your containers and you outputting the Ruby gems, then it still makes it quite difficult to know exactly why that was built and where these Ruby gems had come from. Was there something lost in the form up there. Something around that.

Darko [00:25:54] Sounds interesting. Ruby, Java, all those languages are from 1995 or something like that so it seems that in these days some of the challenges that we are facing today were not very present back then. I don’t have much experience from the mobile development world, but it seems that they are maybe a bit ahead in terms of packaging that. But OK, those are platforms which are kind of under tight control let’s say.

Lee [00:26:26] Absolutely. There’s a couple of different technologies that we do support and we have some others in our roadmap that would be interesting for people to break it into the mobile development.

I think you’re right there – they’re more controlled platforms, so they’re more prescriptive. You sort of follow the vendor who controls that platform and if they say “Hey this is the new language” you’ll be like “OK – that’s exactly the way that we are going to do it”.

For us we’re a lot more “wild west” I think in the cloud world than traditional systems where you’re basically more in control of what you want to do. It would be quite nice to see more standards being pushed like that. Maybe that will be a more boring world where there’s only one technology everywhere. I’m not really sure – I’ll let you know when we get there.

Darko [00:27:19] It would have to evolve over probably a quite a long period of time too and to have many benefits to be embraced on a large scale. Do you maybe have any questions for me or about CI/CD or is there anything that I maybe should have asked and did not?

Lee [00:27:44] The thing for me is that we didn’t really touch upon the link between something like package management and CI/CD –  if we did it was probably quite brief.

You can probably see quite a lot of people doing quite a lot of different things as well in terms of your customers building the systems. One of the things that would be building is tighter integrations with first-class partners such as Semaphore, just to really make that a lot slicker. Is there anything that Semaphore is working on that would probably really elevate that in terms of marketplaces or in terms of you know promoting that?

Darko [00:28:23] I have to say that over the years marketplaces are something that we don’t have really great experiences with as such. However, we did in the previous version of Semaphore have quite a few integrations and that worked out very well – it makes a couple of clicks for people to take care of something. But even if it’s not a couple of clicks, it’s something that’s taken care of and they don’t have to load the whole stack into their heads and to decipher everything to get going. People are very grateful when we build such things or at least document them and maintain that in such a way that they can just take that and move forward.

The most exciting thing in the CI but also kind of a burden that you have to carry is that people are using a lot of very different technologies. I saw on your home page you have more than a dozen different packaging systems that you provide then you can imagine all the tools that people are using to build their software.

For us Docker came here as a great tool – people can isolate them from their environment as much as possible. In terms of Docker and generally all those other packaging formats and technologies people are using I would say that it’s all probably a bit more in favor of packaging systems that people traditionally use than Docker. Docker is huge, however, there’s a lot of software that was written before and it is being pushed into Docker containers to deploy more easily but still, it needs to be packaged and versioned. There is a great opportunity for collaboration in that area of making it easier for people to ship their packages.

Lee [00:30:57] That’s exactly one of the things that we’re trying to deal with as well in terms of simplicity and really boiling things down to be as simple with the least number of steps as possible to achieve their goal.

That’s something that we haven’t completely solved in terms of making it like a one-step process for people getting their software into and out of Cloudsmith. But it’s something that we’ll try to deal with and it’ll all come from integrations with CI/CD providers such as yourselves. Can we make it as simple as possible for people to publish from Semaphore but also to consume assets as well from other locations such as Cloudsmith. You know that’s something that we’ll be looking into to make things as easy as possible.

I had another question as well and this is about your experiences. I wasn’t familiar with the Semaphore pre 2.0 but it’s probably quite a big event to go through a full radical new version of your software and I sort of imagine that with Cloudsmith coming up we’ve got a lot of really exciting things on the roadmap too and they’re probably is sort of 1.0 to 2.0 worthy as well. Maybe you just could tell me about your experiences of doing that jump from the 1.0 approach to 2.0.

Darko [00:32:20] We saw the product maturing and industry has changed in quite a few ways. Docker was one of the huge driving forces there. So our journey actually started from “OK let’s extend Semaphore 1.0 a bit – add a bunch of features”. Along the way after a few months of doing that we just realized that “Hey maybe it makes sense to cut away ties with the baggage we accumulated over the years”. At some point, we said, “We should make that radical change in making version 2”.

Then after just a couple of fixes it kind of naturally came. That’s the journey of deciding to create a second version and then there is a series of decisions that are either made for you or you have to decide. What we didn’t want to do is to alienate the users who are used to the way that things are done in the previous version of the product and there are many of them who are using that product for five-plus years. We decided to launch this new version with the same URL, but essentially you create a new organization and your account. You are free to explore a new version of the product but you can still use the previous version.

I’m very happy that we took that route because people are busy with shipping and creating their software and so on, so they’re not excited about you just now deciding to change the API, the UI, the way that they manage things. Giving that freedom for them to move to the new version of the product when they want it has been great.

On the other hand, there are challenges –  you now have two things running in production and you have to maintain both of them. It’s fairer that we take that burden on us rather than smashing it onto our customers. So far it has been very successful.

In terms of creativity and what you can do it’s kind of a new start. A lot of things that you did from a product or engineering perspective that you were not very happy about but decisions were made in 2011 and you can’t change that. We had been able to make a lot of changes in that area and that’s exciting from a social perspective of enduring theme, of having that freedom and being able to say “Let’s cut away this, we are going to rewrite that thing in a couple of days and it’s going to be a much better”.

I know that there are a lot of products that just keep on pushing that single thing with small and iterative changes and over that time it becomes a monster and there are a couple of these that did make those cuts. To be honest I don’t know a lot of examples but one of those is maybe Basecamp, so every couple of years they create the new version, they leave the previous version for people but then they have the freedom to innovate (a popular word that people like to use) and it really enables that.

Lee [00:36:26] I agree with that philosophy. I think it’s very clever to be able to do that as well and it disconnects you from the customers that just do not want to change. They’re happy with the way things are and it allows you to experiment. A bit like the philosophy for founders – don’t be afraid of change. We’re here to experiment and find what fits best and actually, the things that we thought fit best earlier is not necessarily the things that fit best later on.

Myself personally as a founder, but also as a business, we have to continue to evaluate that the thing that we’re doing is the right thing and it’s not an easy question to answer, so I think that being able to experiment like that is really important and differentiates you from the companies that are much much bigger. Like you said, “the monsters” who can’t move in the same way, with the same amount of grace that we can as startups. We can be very flexible and fluid, but the problems of our customers would be exactly the same.

It’s very very different from the corporate world. I was in charge of developing financial products before. It was a more enterprise/on-premises type scenario and a lot of time we deployed our products and customers would have taken a particular version and they maybe would have held to that version forever. And that was it. They never upgraded it. They never accepted bug fixes, they never accepted new features and they got to be frozen in time for the rest of the time that they held that product. You have to support every single one of those, so this is a different world from that. It makes it easier to innovate.

Darko [00:38:05] There is that moment of us being smaller but it’s also about the market – the people that are using the product. Obviously, there is inertia and some people want to be on Semaphore Classic version forever. On the other hand, our customers (at least a very large percentage of them) are very excited to embrace new and better tools to make their lives better. It’s also a test for us. Here’s this version two and here’s this version called classic and are there any benefits of you moving to the second version. That’s a litmus test…

Lee [00:38:47] Hopefully yes. I’ve got one final question and this would help me as well and perhaps the people that are watching. Maybe there’s an indicator of something that’s coming up for both sides, but we get a lot of questions from people (both existing customers and potential ones out there and also just people in the field) and they say “When is the enterprise version coming along? When is the on-premises edition coming along?”.

As a business we’re very very SaaS-focused and we’re exploring things between full Saas and are there other ways that we can be more hybrid, a bit more fluid with the people that are sort of stuck on the on-premises domain and so we’re working on that, but we don’t really have any plans per se to necessarily have it on premises proposition today, but we sort of see the market changing over time where there are many people on premises today perhaps (and some will remain there probably forever for different types of reasons like compliance and regulation), but we would imagine that a lot of them are trying to migrate into the cloud or away from that scenario. So there’s definitely things that we could do, but the human experience around… I’m sure people have asked for Semaphore on promises – it’s bound to be a thing.

Darko [00:40:09] Interesting topic. Here is like a snapshot of what we kind of think right now.

I remember the times where we were starting and there was that quote from Marc Andreessen about how much software is being produced and then how it’s going to shift the Saas completely and everything. Almost 10 years later it’s still a very much mixed bag I would say and that or a lot of those companies on-premise is their VPC maybe on AWS or somewhere else. Maybe they would like to have those projects isolated.

Speaking with a lot of customers and also potential customers and so on, it seems that even if regulations are not in place or there’s something that is really prohibiting them to go to SaaS world and just send their data around the Internet in a sense, with new projects they would love to embrace everything being SaaS.

However, there is still a lot of software that was written before in a different way and approaches that were kickstarted in such a fashion by inertia tend to gravitate and tend to stay in that setting. One of  our next steps and it’s something that should happen in late Q2/Q3 is that we will introduce an enterprise version, so that you will be able to install it on premise but we are also thinking about what would be enterprise for SaaS – that’s our current state of mind then we are probably going to go in that direction.

Since we started Semaphore it has been 7 years and we have been pushing away from making enterprise from various engineering reasons. Then it’s also about scaling the team and being able to support it. Our state of mind is that there is a lot of opportunities there. It’s something that we would like to tackle. There are just plain requests from current customers and also from people around: “We will love this – can we put this behind our firewall?”.

It’s very beneficial with running in front with SaaS, making sure that product is stable, it answers the needs that people have and then once you have that fit, then it’s kind of the engineering push to make it, package it and offer it as an on-premise solution. Then there is I’m sure a set of legal and all other questions for dealing with that. We will just have to face and see how that’s gonna go.

Lee [00:43:56] I mean I think we completely agree with the philosophy around that and the thinking behind it. When people ask us why we don’t have it on the premises it’s similar. We say to them that it’s a matter of scale but also SaaS is a really fantastic proving ground because it’s very visible to get that rock feedback from the people who utilize it. It’s a sort of centralized platform for it.

We bring people to us, rather than shipping the software by others and then it’s very hard to get visibility on how people are utilizing the software. It certainly would make it very difficult for us to be able to really support the software that was on premises. It’s definitely in the cards for us as well. I think you’ll probably see for us coming up something that’s a midway point.

But I would expect Cloudsmith to stay fully SaaS, perhaps hybrid SaaS via marketplaces, for example, Amazon – we might have some offers coming up, but there’s something else in between that we labeled as Edge distribution, where people want to get their assets to the edge as quickly as possible. We’ve got things in the pipeline related to that. Some exciting announcements coming up too, but I think it’ll be great to see Semaphore on-prem right there because that says to me that you’ve made it – you’re very successful and you’ve got to the point of being able to offer that and that’s fantastic.

Darko [00:45:28] Something that we saw by just observing the industry that’s our interpretation: when you build SaaS that means that you have tens or hundreds of thousands of users which are running on that system. That means that that system can easily support even the biggest enterprise. We have seen and heard that some software ventures are enterprise-first and when they start reaching a couple of hundreds of thousands of users starts breaking because it was not built in such a way to support such a scale. It’s to some extent guess and hypotheses, but I hope that it proves to be true, that it’s a battle-tested thing that is being shipped.

Lee [00:46:23] I might have to trademark or copyright the slogan then, but it’s something along the lines of being able to handle webscale but behind a firewall. I completely appreciate that and you’re very right and we see the same things absolutely.

Darko [00:46:42] Okay so we’ll have a dispute here about that. Web-scale behind the firewall. That’s a good one. Yeah. Great. Well, it has been fantastic talking to you. Good luck with the Cloudsmith. Maybe we can catch up in the future again when we make some major improvements to our products and ship new things. Okay. Thank you very much.

Lee [00:47:20] Okay. All right. Bye now!