On this episode of the podcast we talk with Allan Zimmerman, founder and maintainer of OpenRPA, a popular open source automation platform. Allan talks with us about how he got started in RPA and what he's working on now, including his work with IoT and the open source IBM backed orchestrator Node-Red.
Google Play / Apple Podcasts / Spotify
Interview with Allan Zimmerman of OpenRPA
SPEAKERS
Mark Percival, Brent Sanders, Allan Zimmerman
Mark Percival 00:03
On this episode of the podcast, we talk with Allan Zimmerman, founder and maintainer of open RPA, a popular open source automation platform. Allan talks with us about how he got started in RPA. And what he's working on now, including his work with IoT and the open source, IBM back orchestrator node red. But before we jump into the podcast, we wanted to do a little shameless self promotion. At formuled automation, we don't just create amazing RPA podcasts. We also help companies build and maintain great RPA bots, whether you're just getting started in RPA, or you have any existing projects driving you crazy. We're able to help you get where you want to go when you're on your RPA journey. We offer options from quick consults on selecting automation projects, all the way to full blown implementations. If that sounds interesting, feel free to drop us a line at hello@formulatedautomation.com.
Brent Sanders 00:49
So, Allen, thanks so much for joining us. Allan Zimmerman. You are the maintainer, creator of open RPA. So we know of you've been mentioned some prior podcasts, Tom Taulli, when we had him on, he had mentioned, he spoke with you, and your name keeps popping up in our interviews. And so we had to have you on and it was great, we got an introduction to you. And so thanks for joining, we'd love to get a little bit of your background understanding of what got you into the automation space initially.
Allan Zimmerman 01:25
Yeah, you want the long, or the short version?
Brent Sanders 01:28
I'll leave it to you.
Allan Zimmerman 01:32
I have a background in the hosting industry. Since the mid 90s, I've been working for various hosting and later cloud companies, where my primary responsibility was building and building code in creating and maintaining provisioning systems. So everything from deploying servers, operating system configuring services and maintaining the users, you know, everything. So inhibition, SharePoint, and exchange, whatever, right? All of that fully automated, that is what I did. That's what I do. And, and, and I love trying to get software that wasn't meant to be able to talk to each other, get it to talk to each other. And I love the challenge in trying to automate everything about deploying and maintaining software, usually in hosting/multi-tenant environments. Yeah.
Brent Sanders 02:30
That's interesting. Yeah. I mean, so since the late 90s. I mean, I remember, we're working. That was probably my first interaction myself with like, web based software was getting hosting account set up now, I never ran as a host. But there's a plethora of systems and pieces of software that, you know, you have to sort of string together. And, you know, was that something that you did sort of out of your own house? Or were you hired by another company? How did you get into that?
Allan Zimmerman 03:03
No, that that was my professional job, that that's, that's what I was hired to do. I'm not sure it's correct. But I have the impression that Europe was far ahead of the rest of the world hosting wise, back in the late 90s, start of the 20th century, where the prism interfaces that you have access to in Europe, were very advanced, and could do a lot of things. And they were also very user friendly. where, when, when I saw the interfaces, the some of the US hosting providers have, you know, they were still using frames, and and, you know, aerial farms, and it was horrible to have, right. So, so, yeah. yeah.
Brent Sanders 03:52
you can't eat. I mean, apparently, you guys did not have America Online. In Europe. I mean, that was like the pinnacle in the late 90s. Right is, yeah, Imean, honestly, that was it was is pretty bad. But yeah, so working your way through some of these, I'm gonna use the word primitive, but more of these earlier technologies, getting those two coordinate enters this world of RPA, which, you know, it, it isn't a very new industry, if we, I mean, obviously, it's very popular right now, there are podcasts popping up. And there's everybody writing about something that's very, very new, but this idea of automation and then slapping this term RPA on it, what, like, how do you define RPA? I mean, what, what's the difference between automating and RPA if there is one.
Allan Zimmerman 04:46
So for a long time, I I kept having this idea that RPA was, you know, just screen scraping with a new name. Yeah. Right. And and, and if you look at my products, I still treat it that way, right? I have an RPA robot called Open RPA. That does, what you would do when we are talking screen scraping or, you know, finding windows element and ... and you know, SAP GUI scripting and stuff like that. And the problem is that a lot of companies, and a lot of the executives and a lot of the business people in a lot of companies, they kind of agreed on the term RPA as a common term for anything that they want to automate, even though what they want to do, or what they need is an RPA. So you kind of have to embrace that. That's what the world has just decided that RPA is everything and not just what most robots can do. I hope that makes sense.
Brent Sanders 05:56
Yeah, no.
Mark Percival 05:57
Could you go into more detail, I guess, on what you mean by, you know, what, what they actually needed to do, when they think it's a robot, something that's a robot automation. Well, what's the other side of that?
Allan Zimmerman 06:09
So without getting into a sales pitch. And I usually have this idea that, when people contact me and want to talk about RPA, they want to automate processes. But a process isn't just what you can reach from the domain of a PC, what you can read from running a robot on a PC or console of a server somewhere, a process consists of free items, free free domains, or whatever. So first of all, we have the IT systems. And that would be any system that you have either installed locally on a hosting center, or cloud sends all the software services, something but something that has an API and a user interface. Usually both have just one of them. But usually they'll have both, right. So this is your CRM, your ..., whatever it might be. The other thing that you have when you want to talk about a process is people, not always, but usually there's a person involved either starting a process, or you want to notify them when the process is done. Or you want to be able to tell a person to go do a physical thing and acknowledge that they did it as part of that process. Or you want to have the option to fall back to a person if an automated process fails. And the last domain that you want to look at when you want to automate a process is everything in the physical world. So that would be collecting data from your PLC, your SCADA, your PC, your embedded systems, or communicating with things in the IoT or the industry IoT world where you know, lower set wage, sick folks and so on. Once you are able to tie all those things together, then you can actually talk about automating the process.
Mark Percival 07:56
The really interesting point, I mean, I think there's a lot of focus right now on the site you mentioned, which is the having somebody come in and actually fix an automated process or not fix but to take over a manual piece of it. But that other side you said was, you know, basically notifying someone to do a task? I don't think of any of the RPA solutions that are the big ones are doing that. Is that something that you're kind of focusing on? And how would that actually work?
Allan Zimmerman 08:24
So you asked, How did I get into RPA kind of got away from that. So I've been building provisioning systems for many, many years, and I did different ways and different routes. Every time I jumped to a new company, I want to try out different new models and new ways of doing it. I'm especially when we wanted to build hybrid clouds that was fun. I mean, that's really, really challenging. It's not hard automating something on prem, it's not hard automating something in a data center or a couple of data centers. But creating something that allows you to seamlessly provisioning things, where some is on premise, and some is in the cloud, that is very, very hard. And that I love that that was so fun. And one of the things that I realized while during that where I needed a way to make it easy for customers or someone responsible for a specific customer to change specific things in the provisioning of specific systems because it was tailored specifically to that customer. And what I've been doing for many years where I would add support for easily adding or injecting PowerShell as part of the provisioning system where you can change part of it. But then I came across Microsoft workflow foundation. And you know, I had this epiphany like, Oh my God, why didn't I look at that at 10 years ago when I you know, it was hot, because this salt, a lot of things. It made people you know, the problem was no one knew how to code PowerShell at least back then. A lot of other people wanted to get involved in that and change stuff. So it ended up being me having to make all the customizations anyway. So I needed a way that I could give other technicians or the customers access to make changes themselves. And Microsoft Virtual Foundation was an awesome solution for that. So I started building permissioning system that was based on Microsoft Virtual foundation that will allow you to take control as a part of the workflow yourself or, you know, outsource that to someone else, assigning those paths. And suddenly, I was not alone, suddenly, the customers or the consultants would start doing stuff themselves. So if you then go forward a couple of years, I was part of a company that wanted to train enterprise customers in how to implement and work in DevOps environment while also offering development cycles for big enterprise customers. And that kind of pushed me over to thinking okay, maybe it's time for me to start my own company, I want to make a ton of money now. I started a company with a couple of guys that wanted to offer DevOps. And that was not a big success, we didn't really get a lot of customers. So we were trying fumbling around in different areas to figure out where can we make some money. And since I didn't have a technical role to fill, because we weren't really sure what our product was, I started to develop my own new, you know, provisioning system. For something, I didn't know what the goal were. But I wanted to play around with some ideas that I had. First of all, I wanted to create something that allowed me to build triggers and constraints in a no SQL database world, I wanted something that allowed me to have a distributed system, where I can react on data streaming in from other sources. And the other thing that I wanted was I wanted to play around with how can I can expand the model of giving other people access to automating stuff, more flexible than what I've done in the old systems. So I started building something that could automate that without even having a purpose. And then an opportunity came where a customer wonders to do something where we automate people. So suddenly, that gave me something to use that platform for was adding state to the workflows so we could do human workflows. So we could start automating people. So you could take you know, paper, what's, what's the English word, and, you know, if you have a process that you could put on paper, you can then make a ticket. So by putting it into a system and telling the system to tell the person what to do, and when to do it, and how to do it, and you know, check off okay, I did it, you know, next thing on the list, right. And that's pretty much what a TPM system is, except this system were operational, right? It was not just about going through all the different layers and ending up in a swim lane. And then you have a Word document telling me you are here, you need to do this now. No, you have a system that could actually tell people what to do. But because of spills, based on the platform, that I'm used to where I want to integrate to everything, and I want to be able to automate everything, suddenly, it became obvious that if you tell a person to do something, let's say it's an onboarding process, you know, you have these 20 steps that you need to go through every time you hire a new employee, you can start up by mapping that process up and and now you know, how many onboarding processes are going on, you know, how long they take, you know, into the IT department that is always late or whatever, right? But now you also have a very easy way of going in and automating part of that process. So you could say, why would I send an email to IT about creating a user or creating a ticket in ServiceNow? I could run that PowerShell script myself. Why would I tell the receptionist to order flowers the day the new employee start I can just create a bot that locks on to interflow, one out of the flowers and so building on that we suddenly started getting a lot of traction getting another customers that wanted to automate processes. And a lot of them would say, oh, can you also do RPA. And we had no idea what that was. So, I googled it and came across UiPath and a couple of others, and I contacted them back then you couldn't download a Community Edition and right at the event, right, you had this bowl of fill out your phone number and email and the sales guy will you know, give you a day. So I contacted a lot of these different vendors and said can I get access to the software because I want to control that from my platform. I want to be able to tell the robot to do something at a specific time. And since this is getting recorded, I'm not going to mention names but one of the vendors contacted me and I told him what he wanted to do. And they were like, why would you do that? You don't need developers anymore. You don't need API's, you have a robot. And that was the funniest shit I've ever heard. So, I actually ended up getting a trial version from another vendor called Korean. And, and my first thought were, this is cool. And this is very, very complex. I mean, it took me two days to figure out how to add six to word. And I was like, there has to be a better way to do this. So considering that, you know, I have a background in commissioning systems, and I love room engines, I ended up saying, fuck it, I'll do it myself. So I sat down, install Visual Studio, started building a robot, and based on the rule based engine, because that's what I'm used to. And after a couple of days, I had something that could record me clicking around using Windows automation. And then it could find the elements again, and redo what I do. And my partner's was thrilled and started asking questions and wanting to do a lot of things. And after a couple of weeks, I realized rule engine is just not good enough, I need something else. And well, Microsoft workflow engine, hey, that's a good way. I rewrote everything using Microsoft workflow foundation. And that's how I ended up building a robot. Because I needed something that would allow me to do the things that you want to do with RPA, when you don't have access to an API. And all the RPA vendors on the market didn't want to do a partnership. Because you know why? Yeah. That's how I got started.
Brent Sanders 16:51
And so the project we're talking about is roughly, I mean, this is the now open source project open RPA. Is that correct?
Allan Zimmerman 17:00
Yeah, so the whole engine that I started talking about with, you know, automating stuff and adding human workflows on top of that, that is what I call open flow. Yeah. And, and a little part of that is the end the product that I call open RPA, which is the robot.
Brent Sanders 17:20
Yeah. So look, let's dive into because one thing I wanted to pick your brain about in this conversation is around being an open source maintainer. It just seems like a pretty thankless job. And it seems like it's a difficult thing. I mean, for as long as the project's been running, you know, just quickly looking at GitHub, you obviously you have the vast majority, by far of the commits. Looks like there are pull requests that come through and some other contributors that have, I'm really only looking for the last, you know, year or so. But, you know, talk to me about what that experience has been like, you know, having this project out in the public and in the open. Does it attract weirdos? Does it attract crazy questions? Is it frustrating? Or is it? Is it really gratifying? I mean, because I always have a lot of appreciation for people that do it. And I, you know, for a project like this that's been going on for a while and seems to have quite a bit of adoption. I, you know, your horror stories. I'm curious your perspective on it. What's it like?
Allan Zimmerman 18:26
So doing the yeah, my. Yeah. So my word life in it. I've several times created small projects that I offered people access to the source code with, and it's never been something that that attracted a lot of people, but the few that it then did with no, we benefit and we would help each other. It would be fun, but it wasn't a job. It wasn't something that I had to live on. It was something that I did, because it was fun, right? Mm hmm. So when I finally had the chance to take this platform that I built and make it open source, because I now own it, and I can do whatever I want. I hope that that would attract a lot of people, because when I released open RPA in April 2018, I think it was there was no projects out there that had an orchestrator. And I could only find two projects that had a recorder function and a visual programming interface. But one only supported image recognition and one was only half implemented a little bit of windows, a little bit of image recognition. And it looked a lot inspired by how blue prism does ratings. Service. You know, it was clear that there was a big gap in the market. There was no open source tools for doing this. There was tons of tools for doing RPA. I mean, just look at autohotkey, which has been there for like, what, 20 years or something. I mean, that has tons of flexibility to do RPA. But not what how enterprises work with AI RPA. They don't want to code they want to, they want the visual approach to things, right. So I'm sure that everyone would flock to this project and want to contribute and help and do something, and they did not. So until now, I've been primarily the only one contributing to this project, not because I don't want help, not because I don't want people that just hasn't been anyone offering help.
Brent Sanders 20:43
That makes sense. I mean, it's a lot of, I wonder if that's indicative of, you know, there, there are certainly, I don't want to say it's the language or, you know, the technology stack. But I wonder if it is due to the user base being more familiar, less so familiar with open source technology? Obviously, they're downloading the project. They're trying to run it, they're, they're working with it? And yeah, I wonder what that. Do you have any thoughts around? You know, why you think that might be?
Allan Zimmerman 21:13
I actually think you just hit the nail on it. Yeah, I actually think you're right. Because a lot of the other open up other. Sorry, my times, a lot of the other open source projects out there are very developer focused. And that means that usually it would be developers trying that out and therefore also have higher demands and higher interest in you know, fixing it, if it doesn't work. where most of the people that I meet is the business people or, or acceptance executives that stumble across it, and and they haven't even tried it, they just saw the images and think, hey, that looks cool. I want to not push it, and they contact me. Right? So I don't have a lot of developers per se. Yeah.
Brent Sanders 22:07
Yeah, I think it seems like a lot of the pull requests are translations. And, you know, I don't want to say that, you know, discount any of that, because it's still very valuable to increasing that user base. But it doesn't seem like, yeah, there's a lot, you know, large willingness to hop in and take the project into another direction, which is also maybe, you know, in some ways, a blessing of, you know, having to rein people in or, you know, people going in there in the wrong direction with pull requests that are not what you want to do. But it was interesting, you know, it's always a question that I have when people you know have strong, open source projects that they run, maintain. And you know, I always think of it as a thankless job. But on the other hand, has it been useful for I always think it's a great way to, to find, you know, for business development, find new work and establish yourself as a, I'm going to use the word thought leader, Yes, I did. But putting yourself in a position where you are an expert. I feel like it has been clear to me, you know, your reputation before coming on this podcast is been, I think, largely due to this project. But have you found that to be true as well?
Allan Zimmerman 23:25
Oh, I've heard a couple of questions. said that it's an unfaithful job, and what has been my experience. So I don't have a lot of bad pull requests, as we just clarified. But that doesn't mean that I don't get a lot of requests from people. And I think that's also something that the professional people maintaining big open source projects struggle with. Yeah, is that that I had a tendency to think that if I just give people what they want, and I cater to every request, then suddenly someone will come by and offer me $20 million, right. So I would instantly create whatever people asked for because I thought that that is what it's all about. And, and then other people will start helping and that has been that has taken a long time for me to get to the point where I stopped just doing what everyone asked and and put a roadmap down myself and decided this is the way I'm gonna do it in this order. And unless you come with $25 million, or whatever, I'm not gonna do what you asked. And that has been hard because I don't want to offend people. I just want to please everyone, I just want to make do the best I can and whatever requests people have, I want to try and fulfill that and that has been hard.
Mark Percival 24:53
I bet. I mean, that's my experience with open source is typically the Projects once they start to really gain attraction as the founders or the maintainers have to essentially start to basically start saying no and start building a roadmap. And that's, that's really tough because it's hard to understand, you also are trying to understand what your users trying to do. A lot of times you get from projects that maintain it. So sort of this, like, what are you actually trying to accomplish? Because you're saying you want to do this one thing, but like, maybe that's not what this project is for? Or maybe there's a better solution. And so you kind of play both maintainer and roadmap person, but also like, a consultant.
Brent Sanders 25:33
Guidance counselor. Yeah.
Allan Zimmerman 25:35
That's, that's two things in that, right. The first one is the common support thing where people say, Oh, he can't do that. And then when you dig into it, it turns out that what they want to do is absolutely stupid. And there's a right way to do it. But the other thing, and I think that's more important is if you set out and say, Oh, this technology is fantastic, I want to create a business around this technology, and then everyone will flock to me to buy my awesome technology, that won't happen. You know, you have to build a company around fixing a need in the market, or at least being able to tell the market that they have the need, so they will buy your product. And when I started this, I was not fulfilling a need. I didn't have a customer. And I didn't know who my customers would be, I just thought it would be fun. And I hope that, you know, someone might want to pick it up, and maybe a couple of those would also pay me a little bit of money to do it. So that has also been a struggle figuring out what is really my target customers and what is it that they want? And how do they want it?
Brent Sanders 26:43
And that's, I mean, that's a challenge for any new business. It's, you know, one thing that you touched on, earlier on in the story was around, we use the word orchestrator or orchestration. You know, one of the, one of the most loaded questions, and I think it's a good way to kind of kick off another part of this discussion is, you know, how do you look at orchestration? I know, there's also a word that you use that I prefer, in a way, as you relate to open flow, or introduce it as a back end, for open RPA walk us through I mean, do you see you know, the word orchestration? Like how do you define it?
Allan Zimmerman 27:25
So well, I can go and Dickie. But my impression of orchestrator when you talk RPA product is something that allows you to tell robots to do something at a specific time and offer some simple services to the robot to use, like an Asset Store, a queue system and something like that. And, and open flow is just so much more than that. So that's why I hate calling it an orchestrator. But to parallel it to something that people understand. Yeah, we can call it an orchestrator. But basically, open flow is a secure database. So when you save data inside open flow, whether it's a workflow project, or your files, or your temporary data, or whatever it is, you have access control list attached to all those items. So you can control per role or user level who can access that specific update inside the database. And it also allows you to do underlying description of parts of those documents. So you can decorate documents with a list of properties that you want encrypted. And that will then be encrypted with yours 256 bit encryption. And at the same time, it's also version control. So all objects inside the database have version control attached to it. So you can always see who changed what, at what time and you can roll back and forward in time on the objects.
Brent Sanders 28:57
Yeah, well, that obviously, is a really killer feature. I mean, it's something that Mark and I have toyed with with storing data is, you know, you want that audit trail. I mean, that's a necessary aspect of, of RPA are sort of a facet that, you know, making sure you in the bot doesn't destroy the database is one way of putting it but you know, having an audit trail of, hey, who changed this what being able to go back? And you know, I always think of. Sorry, go ahead.
Allan Zimmerman 29:26
Yeah, but there's several things to that, right. So first of all, I already had the whole structure for doing that, because I built it for something else, not for a robot. So it was just natural for me to create a robot then that would save all its data inside this database. And then you get all these tool features as part of it. So it didn't start with a robot and how do I save data inside the robot, it started with a system that should be able to handle enormous amount of data very, very fast, very, very efficient. And then I just happen to also have a robot that needs a way that he can save data. And the data is twofold, right? That there's the necessary data, the workflows, the projects, the audit log, the history of runtimes, and stuff like that state for workflows, I save state inside my workflow. So if a robot die, so if the machine reboots due to Windows Update, it can continue from where it was and do its work. But when you are building robots, you often also need some kind of state when you're doing that. And so let's say that was an example. Let's say that you, you get, I don't know a thousand things of something that you need to do, you want to keep track of how far down the list that I get of these items that I need to do. And there's two ways you can fix that: you can either save it in an Excel file or comma separated file, you can trade a queue system with work items that distribute that, or you can put it in a database, and then, you know, do it that way. And a lot of the projects that I've seen people use a MySQL or Microsoft SQL Server for that. And that just felt stupid to me. So that's why I try to make it very, very easy to use the built in database that is part of open flow, where you get the whole security element as well. And then because it's not going to be you also get access to grid Fs, so you also get access to fast and efficient storage of files. So now you can have a central place where you both have your state, your work items, your temporary or permanent data and your files, and you can easily distribute it and access it from PowerShell, from API's, from node reds, from robots from anywhere that you need.
Brent Sanders 31:53
Yeah, so I mean, it's, it's a super powerful stack, you know, going off of you know, what you've listed, as well as what's on the readme on GitHub. But when you look at a toolset like openflow, what's a what's like a perfect use case for it? versus what would you if somebody is thinking about using this or think about, you know, it's kind of loaded, because this is, it's a little bit more technical, I'm trying to relate it back to some of our non technical listeners, however, I'm trying to put it in terms that, you know, if you're on a platform, and I guess it really isn't directed towards a non technical audience, so it was kind of fruitful, even to kind of go down that path. But, you know, what's a good use case, what's a bad use case?
Allan Zimmerman 32:39
I would turn it around and say, I have three types of partners using my product. So I have the traditional RPA implementers, you know, they need to implement something using robots. They look at the commercial vendors. And sometimes they find the customer doesn't want to pay, or they find a government institution that has a policy around always using open source or whatever the reason might be, and they contact me become a partner, and they start using my robots as part of their solution. And those people, they only need what an orchestrator could be, they need a place to save a couple of days. So they need the cue system. They love the easy low balancing plus robots and, you know, managing, you know, high density robots, stuff like that. But beyond that they don't really move on, then I have some partners that use this as an integration engine. So the whole human workflow part, but also the fact that it comes out of the box, which supports more than two and a half thousand different IT systems. And it's very easy to extend to talk to pretty much any API, either soap or rest or whatever, right. So it becomes a very powerful engine to integrate a lot of different systems. And most of those type of partners or partners, that is actually building their own platform for something. And they just need a good infrastructure, you know, good stack to build that on top of and they chose open flow for that. And the last type of partners that I have kind of blends into two roles. One is the people that is focused on IoT, they need something that makes it very, very easy to integrate to any kind of device and not just vendor specific devices. And since no dread, can talk any IoT protocol that exists on the market right now, and we can plug it into a Raspberry Pi and add whatever radio adapter we want to we now get very easy access to deploy a lot of devices using low consume hardware instead of buying all the expensive stuff. And that and because the way open flow is filled it also support ..., you can now build very, very advanced and complex network topologies where you're collecting enormous amount of data. But open flow slash node red also supports talking to old school systems. So, PLC, SCADA , ..., OPC server, or ..., whatever it might be, it also supports .... to those kinds of systems, so it kind of bridges the gap between the old way of automating things in the physical world and the new way. So we can call it industry for IoT or smart city, smart grid, whatever, I don't care. But there is a need in the market for a solution that allow you to take control of your own data and own your own data, and not be dependent on vendor specific solutions or something that wants to put you in the cloud, and you have to pay to get access to your data.
Brent Sanders 35:44
Yeah, so that's a great overview. As part of that, you know, you mentioned node red, which maybe you give us a little bit of background as to what how you came across the project. The first time have you been familiar with it? For obviously, it's, you know, a huge part of open flow, it seems like, and that.
Allan Zimmerman 36:04
I would say it's the core.
Brent Sanders 36:06
Yeah, so it's, it's this? You know, it seems like that's the piece when you say you have access to 2500 integrations, I believe, you know, that's from that core, being no red. I mean, could you walk us through the history or what you know, about that project?
Allan Zimmerman 36:24
So I'm not hundred percent sure and have the history correct. So if someone wants to kill me afterwards, feel free. But as I, as I think it is, and I'm not 100% sure, I think that node red started as a hobby project for one or two guys working for IBM. And they were trying to build, what would kind of be the equivalent of the Asia event hub or the top subscriber in Google or you know, stuff like that, something that, you know, and something that would allow you to handle an enormous amount of events very, very efficiently. And, and they decided to make that project open source. And then at some point, I don't know when they gave that project or audit of I don't know how that happened. But somehow, the note's foundation took over. But it's still the same guys working at IBM that is developing this platform. Very, very talented, very, very cool, guys. And how did I find it? Well, so Microsoft workflow foundation is a very old technology. It was introduced in dotnet35, it was revamped completely in dotnet form. And it got an overhauled in dotnet45, and a small couple of updates in dotnet46. And since then, and that has been, I don't know, 15 years, it hasn't been updated. Yep. But pretty much every Microsoft service that you can think of back then was based on Microsoft Workflow foundation. So SharePoint is using its CRM was using it PowerShell is still using it. A lot of Microsoft products was built on Microsoft Workflow foundation. And I'm not 100% sure on right here, but I also think this talk was based on it. I'm not sure if it's on top of its similar code base, but at least, it's pretty much the same thing, right. So it was a very cold thing for Microsoft. I don't know why they stopped developing on it. But maybe it's part of Asia logic, or Microsoft Flow, as it's called now, or whatever they call it, like they keep changing the name. But the whole idea of moving the workflows to the cloud and forcing customers to pay them a little fee per activity that you call, I don't know. But it was a very, very, very, very good platform, and very scalable, very robust. And the whole idea of building a transaction based workflow engine was done so good, and so correctly. And that's why a lot of third party vendors are still using it. I don't know. ServiceNow still using it, but they were using it as a core for a long time. And tons of companies out there. And, you know, also some of them those that, you know, like UiPath, and racks and another Monday and me. Yeah. Yeah, that was a final read. Well, there was a lot of debate for a couple of years about, when would Microsoft come with an update? When would they migrate this to dotnet core. And Microsoft wouldn't come with any announcement, you know, either going, you know, committing to it or putting it in degree. And, and that's about the same time that I started my company. So I was looking at these threads going on on different forums about you know, when will Microsoft do something, and at some point, someone came with the idea that maybe we should might write this in an open source version, you know, under dotnet Core and then maybe use other open source project as part of that and then someone linked node red in that thread. And that's where I came across it. And then a couple of months later, then Microsoft officially announced that they're putting it in the grave. And if someone wants to open source it, they can do. And I know some guys did a lot of work on migrating part of the Microsoft workflow foundation to dotnet core. And I don't know if it died, or it stopped or whatever. But for some reason, the GitHub repost the sub list showed up at UiPath. And as far as I can see, most of my years of workflow foundation except the UI, which is kind of the most important thing, I mean, that's the reason you want to use it. There's tons of open source workflow engines out there, but they don't have that cool interface user interface, as Microsoft Workflow does. So not migrating that kind of puts us in the grave anyway, right?
Brent Sanders 40:50
Yeah. Right.
Allan Zimmerman 40:52
I bet you I've have is working on their own version that will not be open source. Yeah, I don't know.
Brent Sanders 41:00
So, um, you know, as you look towards the future, for open flow, it seems like, you know, open RPA is continuing to be seems like a great tool for screen scraping a lot of the, you know, I don't wanna say basic uses of RP. But it seems like that's a little bit in your rear view. I mean, obviously, you're still committing to it, you're still very responsive, from what I can tell through GitHub. But as you're kind of looking forward to what you're spending your time on how you're spending your time, it seems like open flow is sort of this larger project that is maybe a little bit more interesting, but is much broader. Is that right?
Allan Zimmerman 41:43
When it's always been, I mean, the main goal here has always been what I call open flow now, and the robot were just responding to a need. And it just turned out that that need gave me a lot of publicity. So I'm stuck in this weird road where I can't really give it up, because it's giving me all this attention, and I love the attention. But at the same time, I don't believe that the future is RPA. I believe that RPA is a powerful tool, I believe RPA has a role to play, but not the same way that most other vendors do. And that's why I really, really, really, really insensitive, the users to try and have an API first approach to everything and not use the robot unless you have to.
Brent Sanders 42:39
That makes a lot of sense. What do you think? I mean, obviously, there's an entire industry future, but like, where do you kind of see more of like the technology at large? The trend heading? I mean, you would assume that over time, I mean, for Mark, and I a lot of the origination of this podcast, and our interest in RPA has been around just legacy software, and where legacy software is going to go in the next 5, 10 years? And is it going to eventually be replaced? And you'll have that ability to adapt it to API's and things like that? I mean, what do you see this? I mean, it's kind of a loaded question, because I'm what I'm really talking about is, where do you see, you know, technology in general heading, but as it relates to automation, or the projects that you're working on? I mean, what do you want to see happen in the next five years? 10 years or so?
Allan Zimmerman 43:31
So I have absolutely no base of saying that these numbers are correct. I'm just throwing it out. But I think it's roughly correct. If you look at, I don't know, 80% of the IT companies in the world right now, what they're doing is that they're building some kind of integration between two or three systems, that they are building something that very tightly integrate those systems with each other. Or they're building something that can collect data with one view and present the data in another view, right, you're putting stuff in the database and presenting it to users with different primary keys or whatever. Right. So that's what IT is. And what is going on with the whole automation hive is that we are making it easier to integrate system and integrate a lot of systems. And and and that's a train that has started that will not stop. Yeah. And I mean, back in the 70s, there was a lot of research done into machine to machine communication. And it's kind of weird that that died. Because one of the things that RPA fixes is that it allows us to make sure systems communicate with each other that originally couldn't talk to each other, or didn't know how to talk to each other. And, and and a lot of people say, oh, but there's an API, we can fix that. Yeah. But API's is not made for machines, APIs is made for people so people can figure out how Can I talk to that system. So you still need a person creating some software that make those two systems talk to each other. But there are actually a lot of research and it's starting to become hard again, in how can we create a terminus systems that can learn to talk to each other automatically, and then start communicating and getting value out of that. Hmm. And so once that is there, and that's not there now, but it will come, I believe, that will make a lot of RPA use cases obsolete. And the other thing that resources that a lot of the system that we built until about five or 10 years ago, we're not user friendly, the whole idea of UX and usability and making sure you have access to the right information. easy and accessible, where you are in the context of where you are, was not something you evaluate right. So it's normal that creating a user meant clicking on eight tabs and typing in the same information 10 times. And robots have never ever good at that. So as most system gets replaced with newer systems with better UI, the need for robot is not really that big anymore.
Brent Sanders 46:13
Definitely I mean, I can't, I guess, I think about RPA is, or even automation is sort of an interim phase, right? It's, it's, it's this thing that we need to do in order to get us. So we're not doing things manually. And you'd imagine that these things go away. However, if you look at most legacy software out there, you know, a lot of these systems, once they start becoming a problem for somebody, they're quickly forgotten. And so there's always this, you know, again, this is more of a, I think, a symptom of a given organization or, you know, a symptom of a larger problem. But I guess it's hard for me to be fully convinced that things will consistently improve, or will they only improve when they become a big enough problem?
Allan Zimmerman 47:05
Yeah, but maybe my answer wasn't quite what you were looking for addressing the right thing. But so a lot of people say, you know, RPA is dead, or RP is not relevant, or RPA is the wrong solution. I disagree. Because RPA is very good when you're talking legacy systems. Not legacy system is the way that your former guy that was in here, I can't remember the name. The cool guy that loves fixing bugs, yeah. But legacy systems in that you have systems that was built many, many years ago, and maybe you even stopped developing on them. Or maybe you're just maintaining them with COBOL Developers, I don't know. But no system that doesn't change a lot. RPA is very good at becoming an API or a bridge on top of that system. So that's cool. But the most value of RPA comes in that business people are used to go into the IT development to the IT department and get an URL, right. And every time it goes to the development partner, they get told, well, that's going to be very hard. And we have a backlog where things can disappear for six months. So you know, when business people need something done and time to market is important for them, they get tired of these two department constantly not being part of what makes the company progress and make money. So RPA gives the business people the opportunity to either themselves or through partners that know how to work a robot easily figure out what is it that I need? Because you know, the IT department hate business people because they always come with software. And developers hate them. Because every time they describe what they want, it wasn't what they wanted. We have all the days of. No, you didn't. Oh, but it's only this and this? No, it wasn't, you know, it's always more complex and more annoying. So RPA gives the business people the chance to figure out what is the process actually what is actually involved in this process. And that means when they go to the development part and say, this is what I want. And I know this is what I want, because it's running in production right now. And that is powerful, that is very, very powerful. So what I'm trying to do with my platform is when you want to transition from being pure RPA and combine it with more API's and a better way of automating it. I try to build a platform that makes that easier, that trade that hybrid of both API's and RPA. I think I nailed it in trading something that made that transition easier and faster and better. Or at least more secure.
Brent Sanders 49:43
Yeah. Yeah, I think that's a good way of putting it. Mark, did you have any questions you wanted to throw out there? We're getting a little bit short on time, but uh, definitely want to throw out any other questions as you see it?
Mark Percival 49:56
No, I think this has been really interesting. I think, you know, coming at it from we've always looked at it from yeah, and node red. I think having played with Microsoft Workflow Foundation, and diving into that, and then realizing how much of that how much stuff that ran. It's interesting to see node red kind of coming up and becoming kind of the next the next workflow. I hadn't really thought of that in that way. But that actually makes a lot of sense.
Brent Sanders 50:19
Yeah, thank you so much for coming on. I think this has been really interesting episode, especially for people that want to know what's going on under the hood. And especially as it relates to like, where the future is heading. I think what you're describing in your last statement, kind of want to let that the piece that kind of comes out in this episode, so thank you very much for coming on and sharing your perspective with us.
Allan Zimmerman 50:47
Thank you for having me. It was a pleasure.
Mark Percival 50:51
Thanks, Allan.
