Pekka Klärck is the founder of the Robot Framework. He is also currently the Lead Developer for the Robot Framework Foundation. In this episode, I’m sitting down to talk to Pekka about this framework, it’s origins and how it can help automate testing and other tasks for applications on the Salesforce Platform. If you never made it to a Robocon, take a seat and get acquainted with this great tool to put in your toolkit.
Show Highlights:
- Why it was always important to Pekka to make his framework open source.
- How the framework came to be and its current state.
- What languages the framework supports.
- What it means for it to be a keyword-driven approach.
- The common design pattern people use with the framework.
- The design goal for the framework.
- New features on the roadmap for the Robot Framework.
Links:
- About Pekka: http://eliga.fi/
- Robot Framework: https://robotframework.org/
- Robot Framework Foundation: https://robotframework.org/foundation/
- Robocon: https://robocon.io/
Episode Transcript
Pekka Klärck:
Like these few years, we’ve changed the generic automation framework because it can be used also for other automation. Test automation is where it came from and it’s still very important, but you can also use it for other process automation. RPA and stuff like this.
Josh Birk:
That is Pekka Klärck, founder of the Robot Framework and currently the lead developer for the Robot Framework Foundation. I’m Josh Birk, your host for the Salesforce Developer podcast, where you’ll hear stories and insights from developers for developers. Today on the show, we sit down and talk with Pekka about the framework, which has its origins as his Master’s thesis.
Pekka Klärck:
Still about the thesis. The original idea was that I wanted to study that what kind of companies will be… implement so when implementing automation frameworks, we didn’t need to build everything from scratch. That maybe we could use some kind of a common logger or something like this.
Pekka Klärck:
The major finding in the thesis was that it’s actually possible to create a generic framework so that you will need to have only the components that you use to build your core framework with. We can actually create a generic framework as well. It wasn’t yet part of the thesis prototypes, but that was finding based on the prototypes. Like, this would be possible.
Pekka Klärck:
I had those ideas then when a colleague of mine with whom I had been working in an earlier automation project had joined Nokia and they needed automation solution for a very heterogeneous environment and contacted me. Okay, do I have any ideas? And I said, well yeah, I have much better ideas than we had earlier. Went there, presented what I had been studying, ideas that I had and they liked it. Then we started developing the framework there. In 2005-
Josh Birk:
Gotcha.
Pekka Klärck:
I think, so 15 years ago. Something like this.
Josh Birk:
Yeah. Interesting. So your thesis was kind of the prototype for the robot framework and then Nokia gave you the ability to start putting it into real practice?
Pekka Klärck:
Exactly. Yeah. When I was writing the thesis I had ideas that okay, this would make sense as an opensource framework as well. But when we started Nokia, it was for internal uses only, but I from the beginning wanted even there to keep the core generic and then extend it with the customer libraries in different product lines and so on. Then this colleague of mine who got me there also fought with lawyers and we got permission to opensource it in 2008. So it’s been also available as open source over a decade now.
Josh Birk:
Gotcha. So then the original intent was always for it to be open source. Why was that important to you?
Pekka Klärck:
I got a feeling that this kind of framework that we have which can be extended with libraries and so on works better as an opensource solution so that everybody can contribute to the wider ecosystem. Of course, people can contribute to a paid solution as well, but that’s less likely. Also of course I had this idea that I thought that would make sense, but I didn’t have resources or anything to start a product company. I wasn’t sure, would that fly? Also, if I would have started a product company, I would have ended up thinking about how to handle licensing and stuff like that, which I wouldn’t have enjoyed. I was interesting to get this framework working and in that way open source was good.
Pekka Klärck:
Also most of the time in writing the framework, I’ve been paid by Nokia and then by the Robotic Framework Foundation nowadays, so it has been kind of that way safer. I like most open societies. I don’t have anything against paid software either, but I think in this case having the core available as open source is better for the [inaudible 00:03:45]. Maybe I have that kind of feel thing that I want to make the world a bit better place in this regard. Well, it doesn’t really stop the wars in the world or it doesn’t save the people from hunger or anything, but at least it hopefully helps people doing testing to make their automation work easier.
Josh Birk:
Tell me about the Robot Framework Foundation. How did that come to be and what’s the current state of it?
Pekka Klärck:
Oh yeah. Good question. Nokia was sponsoring the development for a long time, but it was becoming evident that they are not going to do that forever because it’s not their core business and the framework started to be good enough for the [inaudible 00:04:25]. There’s always managers are changing and priorities are changing so it is always kind of a risk that it might be discontinued.
Pekka Klärck:
Around 2014 I think, ’15, something like that, companies in Finland that were using it a lot, like consulting companies selling services that relate to framework. They kind of started, a bit worried that what happens if this Nokia sponsorship would end. Then the foundation was formed to support the development. Kind of incidentally, it was like half a year after the foundation was founded, then Nokia sponsored [inaudible 00:05:06] so it was about the right time.
Josh Birk:
Nice.
Pekka Klärck:
The idea of the foundation is that they collect money from foundation members, of course. Nowadays we’ve also got some money from conferences. We’ve organized RoboCon conference three times and we are planning to have an online conference in the future. So that way we collect money and then spend the money for paying developers, developing the framework, and the process and libraries and tools around the core framework.
Josh Birk:
Gotcha.
Pekka Klärck:
The idea there is that this is a nonprofit, and making sure that the framework is there that’s developed further-
Josh Birk:
Got it. I want to follow up on that, but I think that’s also a really interesting point that the importance of this being open source is also the fact that like for instance, I know internally at Salesforce, especially over at the dot org side, we use a lot of the robot framework and it’s like, even if you stopped developing on it, the foundation kind of makes sure that it’s going to continue on in some form that somebody could continue using and not have to basically completely upend their automation framework.
Pekka Klärck:
Yeah, exactly. That’s first of all one of the benefits of open source in general. That you know that nobody’s going to take the code away from you. That even if the developer stopped developing it further and so on, you still have the code, you can use it freely and you can develop it further either internally or resurrect the project publicly or whatever.
Josh Birk:
Right.
Pekka Klärck:
If you want to. That’s really nice, but also with the foundation the good thing is there’s this kind of backing. It’s not that I’d be working on this without pay, which would be not maybe so motivating all the time. I [crosstalk 00:06:45] needed to have other jobs to pay my bills.
Josh Birk:
Right.
Pekka Klärck:
Or if something happens to me, be it the buzz factor, or just a burnout of bad motivation loss or whatever, then there’s always the foundation there to take care of somehow. So That makes it also safer to adapt to.
Josh Birk:
Okay. So we’ve talked a lot about how Framework came to be and how it grew into open source, but let’s get into more details about the framework itself. I think you’ve touched on this a little bit about some of the key components of the thesis, but let’s start with the elevator pitch. What’s the elevator pitch for the Robot Framework?
Pekka Klärck:
It’s a generic automation framework. Yeah, very quickly that’s what it is. So it’s a generic automation framework.
Josh Birk:
Gotcha.
Pekka Klärck:
If I tear it down, generic basically means that you can use basically with any interfaces and so on. Not the core framework or [inaudible 00:07:40] unit, always libraries. That’s the architecture there. You have the core framework that handles parsing the data and executing test cases and creating logs and reports, but then to interact with systems then for that you need libraries. You have lots of ready-made libraries available, but you can also very easily create your own. So that’s what generic means.
Pekka Klärck:
Automation framework here means that it’s not only a test automation framework. We used to actually call it a generic test automation framework, but the latest few years we’ve changed that generic automation framework because it can be used also for other automation. Test automation is where it came from and it’s still very important, but then you can also use it for other kinds of process automation, RPA, and stuff like this. So, not only test automation.
Pekka Klärck:
Framework, well, it also means that you have libraries and so on. So it’s not one solution that you just take this and then it solves everything, but you basically take the core framework and then you have libraries that you need. Maybe some ready-made ones, maybe some you create yourself. You then have external tools, editors, you have editors and editor plugins, you have maybe continuous integration and so on. From those components, then you’ll build your higher level framework that you then use.
Josh Birk:
Gotcha. That’s interesting. So it kind of resides adjacent to X and X could be Cumulus or X could be Jenkins or X could be Selenium, and you’re just providing the tools to interact with that and have processes move things down the chain, so to speak.
Pekka Klärck:
Yeah, typically it works so that there’s a CEI then that could be controlling robot framework. So you have CEI system that launches it maybe based on an event that we got new code committed, or maybe it’s a scheduled run, something like this, and then the framework is called, but then it can use internally to Slack, Selenium or Playwright or… Well, if you’re doing web testing, but then other tools if you’re doing something else like UI testing or REST API testing or database testing or whatever. So that’s kind of… Libraries are in a sense below this framework, but then there are these CEI stems and whatever pipelines then, kind of above it. That whole thing then, with whatever you need. Maybe you would need and want containers, you have those. All of that is what makes your final automation framework.
Pekka Klärck:
It’s definitely not the same in different projects because the project needs are different than this framework. It tries to be very open in a way that how you can use it, so it’s very easy to adapt. That’s a strength, but also of course, it’s kind of funny. You start using it for the first time, it can be a problem. There’s some kind of a learning curve because there’s no ready-made way that, okay, you always do it like this, because how you want to adapt it, how you want to utilize it depends on your context and your needs.
Josh Birk:
Got it. So it’s not like for instance, I’m thinking of my early days with Jenkins where you basically just install it and then you go find somebody else’s Bash script and then you rewrite the Bash script a little bit and you’re done. It’s a little bit more flexible, but also more amorphous because of the way it’s designed.
Pekka Klärck:
Yeah. Well, Jenkins is also, it’s a CEI tool not like automation tool. I think if you would compare it, for example with commercial automation, all that would be dedicated for example only for Windows, but overall, web testing and Windows UI testing. Then when you buy it and install it, you have already made a package that covers that and that’s it. If that’s what you need then that can be nice, but if you then need something else, like you need REST APIs or database or something, it can be then more complicated. But with this framework, you need to basically tell X what you need.
Pekka Klärck:
It also means that in bigger project that at least there are different users. There are those users who are setting up the environment and making decision at what libraries we use, maybe creating their own library, setting up guidelines and so on, and they need to of course know the framework very well. But then for the end user, when everything is set up, it should be pretty straightforward and simple to create those test cases because the language that you use is pretty simple.
Josh Birk:
Nice. And what languages does it support?
Pekka Klärck:
Robot Framework itself is implemented using Python. I guess we got somewhat lucky with that when it was not that widely used, back when I started writing about framework prototypes. I actually, whenever I was writing my thesis didn’t before that really know Python even. It just seemed like a cool language. I had experience with Perl but I failed. It was a bit like maybe to [magic 00:00:12:32], but I like the fact that it’s scripted and it’s easier to make prototypes. So I picked the Python to learn it as well and it’s been over the years getting more and more popular all the time. So that’s good for us.
Josh Birk:
Gotcha.
Pekka Klärck:
So yeah, the framework’s implemented with Python and that’s most of the time also what you use when even you extend a lot framework with those custom libraries or with other tools. It runs also on Jython which is a Java implementation of Python and then you can create libraries using Java, but that’s not any more made. It’s not going to be that relevant anymore because unfortunately Jython doesn’t support Python trees [inaudible 00:13:12] and we are relatively soon going to drop Python 2 support because Python 2 is not even… Well, has reached its end of life, so Python 2 is not supported and we are not going to support it too much longer. Our next major release will still support it mainly through Jython, but the idea it was anyway that… It was really important back then during the Nokia days, it’s better to be able to use Robot Framework on [inaudible 00:13:38].
Pekka Klärck:
Python is what you mostly use, but then when writing libraries, we have so-called remote library interface that allows you used to basically any language you want. We have some remote server implemented [inaudible 00:13:50] and ready-made, but you can also create your own if needed. So that allows you to create libraries using other languages as well. Also from Python you can call other languages depending on okay, so that might be a way. Then if you are, for example, implementing a tool for processing results, then the results you get them in XML so you can use any language of course, and process it with the XML and do something with that information, it doesn’t need to be Python.
Josh Birk:
Gotcha. Nice. So it’s very flexible in what it can also talk to you. If I have a node script that’s running some part of my build process, my nodes could still talk to the Robot Framework.
Pekka Klärck:
Yeah. You can run those scripts as processes. That’s one simple way. If that’s a script that you can run from the command line, you just execute as a process. Or then if it has ready-made function, you can use this one for individual keywords, then maybe you expose that as a remote, with the remote interface or something like this, but there’s typically always a way. What the way is of course depends on the case.
Josh Birk:
On the specific… Sure.
Pekka Klärck:
Yeah.
Josh Birk:
Now describe what it means for it to be a keyword-driven approach.
Pekka Klärck:
Oh, good question. A keyword-driven approach for test automation means that basically you construct your test cases, or task if you’re doing other kind of automation and testing. You construct them from keywords that also some [inaudible 00:15:22] calls them action words or something. They do something. You have a name and basically that’s a string and then you call that and you can give it arguments, maybe keyword can also return you something and so on. That’s how you do it. You could have a keyword, like click button, and then that obviously clicks a button and you probably are going to give it the ID or some other locator of the button to click and so on.
Pekka Klärck:
Then the keyboard clicks a button and if it, for example, doesn’t find that button to click then it probably fails. There is an exception and it’s considered failed. Or you could also have a keyword like buttons would exist that it’s going to do a validation. Do you have a button or not? If you do, then it just passes and everything is fine. And if you don’t have that button, then it will fail. So that’s how you construct those test cases. You basically built them from keywords. These keywords that with Robot Framework, they come basically from two different places. We have libraries that are implementing most of the time using Python, as we have just discussed, so they can implement keywords. If you would have, for example, that click button keyword, it basically would be just the Python method of function, that name. Maybe like, click button with all lowercase and separated with underscore or something like this. That’s how it would be. Just like a regular button function.
Pekka Klärck:
Then either they collaborate [inaudible 00:16:49] use and the robot knows that you have this kind of keyword and you can call it and then if the keyword raises an exception, the framework considers the keyword failed, and otherwise it’s passed. So, all the keywords actually do something concrete. They always come from libraries, but one of the really powerful features of Robot Framework, one of the features that was actually described already in my thesis, is that you can construct your own higher level keywords using more or less the same syntax that you use for creating test cases as well. So you construct test cases from keywords, but you can also create new keywords from keywords, and then you can use those keywords in your test case, which means that you can have whatever abstraction layers you want.
Pekka Klärck:
You can have three domain-specific languages, even though you were using ready-mades libraries that are not created by you that could be very low level. You can still create your test cases in a domain-specific language that is then constructed from your own higher level keywords, what we call often also user keywords, that then call other user keywords perhaps, or library keywords and so on. So you have keywords everwhere.
Pekka Klärck:
Then in the end, then always the lowest level keyword is from a library and then that’s actually going to do something concrete, like clicking the button.
Josh Birk:
I think it’s interesting. Robot Framework got on my radar with a conversation that happened on Twitter, where Jason Lance, former podcast and does crazy mad science stuff with build process and salesforce.org… He was actually showing me this inaction on our side of it earlier this week and what was really cool was how that layer of abstraction that you’re talking about solved a huge problem when it comes to UI testing, because especially the Salesforce UI changes all the time and so when you’re talking about that click button event, well, maybe some designer slapped us a different design class onto that button and now that that test is going to fail because Selenium doesn’t know where to find that button. But Jason’s like, but it’s just a keyword. Like, I change it once and then I just expose it as Click Button and all of my other tasks, and that we just push out an update and we’re done and we’re good. Is that a common design pattern that people use with the Robot Framework?
Pekka Klärck:
Yeah, obviously idea is that those higher level keywords they definitely as you just said, they enable better maintenance by, that you can have for example, those button ideas. So whatever locators inside those keywords, and you use them if you want to click certain button. You don’t use that ID in any other place than in that kind of higher level keyword.
Pekka Klärck:
It also helps that your test cases then are much more readable on top level when you can have like, keywords that are like sentences, like log into the system or something like this instead of saying Click Button and then some strange looking [Xbot 00:19:48] expression for example, that would click a button or whatever. So you can abstract things away. You can hide the details and then also get better maintainability, maintenance support with these keywords.
Pekka Klärck:
Yeah. So that doesn’t mean that you always need to do that. You don’t always need to write your addition higher level keywords.
Josh Birk:
Okay.
Pekka Klärck:
Especially if people were using the framework, our programmers, they might be annoyed that they need to create these higher level keywords in Robot Framework, which is of course inferior programming languages compared to, for example, Python.
Josh Birk:
Right.
Pekka Klärck:
It’s just this test description language that has certain programming capabilities, but if you need to do real programming, you go to library site. So you can have also all your keywords in libraries. That’s totally possible as well so that your key libraries, library keywords can also have describing your names. They can even have like non-word characters and so on via decorators and so on. So you can freely create keywords in libraries as well, if you don’t want to use Robot Framework for anything else than describing your test case and then have everything else in Python.
Josh Birk:
Got it.
Pekka Klärck:
But how you do that totally depends on the theme. So if everybody’s a Python programmer, that might be a great way because then it’s easier. They can be in Python most of the time. They just describe those tests in higher level language that is easier than for managers and other, that kind of stakeholders to read. But then if you have non-technical people who are also participating in automation, they can then utilize this other approach. They can create their own keywords and Robot Framework language.
Pekka Klärck:
As I said, it’s not as powerful as Python, but it’s also much easier to use for simple cases. So it’s easier to start doing this kind of automation where you actually do all own keywords, even if you aren’t a programmer. Then maybe in the long run, you learn a bit more, and then you can actually even start looking at the Python side and you’ll become a programmer.
Josh Birk:
First of all, I’ve got to say Python is actually one of my favorite languages. We also share a little bit of history because my first… Now we’re twice aging ourselves because we’re both Commodore 64 kids. Also, my first work with intranets was using CGI with Perl-based CGI. Every now and then I just like to throw it to developers, “Any Perl developers still out there?” We’re a slowly dying breed, unfortunately.
Pekka Klärck:
Yeah. Well, back when I was doing Perl, I think I had already at that time when I learned Perl, I had been writing some Java at school and that was so verbose and stuff like OpenFile. We are talking about like, just Java 1.2 or something like that, required so many readers and whatever. When in Perl, it was like open or die, or what was the idiom to do it? It was like, this is so easy. So that’s why it was easy to get started with writing automation code with that. But then I also at some point realized, okay, this is not… When I need to have some kind of a bigger project, I may want to have object-oriented features and they were pretty good in Java compared to Perl.
Pekka Klärck:
Then Python for me, it was a really nice middle ground with objects and features that allow you to create a maintainable program, but also then easy-to-open files and stuff like this that is important when you are implementing automation solutions. Of course, Java has got much better since that as well. But yeah, this shows our age, I guess.
Josh Birk:
Just a little bit. One of the things I love about Python, I think Python might be one of the hands down, most readable languages on the planet. When Jason was showing me his test scripts, it really reflected what you were talking about before, where it’s like, this is so human readable. It’s like log in, click this, click button, enter text. It’s very, very straightforward and just getting the job done. Was that a design goal of the Robot Framework or did you just get that for free because of the readability of Python, or a little bit of both?
Pekka Klärck:
How Robot Framework tested it, it looks like it isn’t that much infected on how Python looks like, because of course we could have implemented say, [inaudible 00:24:10] keywords and so on using Java. Still nowadays, you can use Java-based libraries as well, but you’re right, Python itself is very readable. But still, if you’re not a programmer it’s not that readable, unless of course if you try to make it so that you really, really make sure that you’re top level, like a test case in Python. If you were implementing Python, would have really high level internal kind of method names, and it would be calling helper functions. You may be able to write something, but still for casual people who are not programmers then, all those using an underscore, not a space to separate words and call ons and parents and whatever. They are just kind of a distraction.
Pekka Klärck:
Also with Python, although it’s quite easy to read, to some extent also easy to edit, but then there’s this indentation that is pretty strict and if you are not aware of that, you will get such strange errors and so on. The idea with Robot Framework is that it’s still kind of higher level and something that you should be able to understand. Of course, it depends on how good your test case is in general, but it should be easy to understand what the test case is doing just by reading it, if the test has been done somewhat well.
Josh Birk:
Yeah, I have to confess my first foray into Python was writing a module for a search engine and I shook my fist at the screen for probably a good two, maybe even three hours wondering why my code wasn’t working correctly, and then I realized it was because I was indenting it the way I wanted it to, not the way Python insisted that it have.
Pekka Klärck:
Yeah. You need to do it like Python wants you to do, otherwise it won’t run.
Josh Birk:
Right? Like, it’s very readable, but because it has its own set of rules that are not negotiable and you have to follow by Python rules in order to get it to work. Which is another thing I kind of like about it.
Pekka Klärck:
Yeah, I’ve had colleagues who really didn’t just want to use Python at all because it was forcing them to use some kind of indentation, but yeah. It doesn’t bother me at all.
Josh Birk:
Gotcha.
Pekka Klärck:
The great thing is that it’s quite hard to make a total mess with Python code because at least indentation you cannot miss if you want the code to work.
Josh Birk:
Right. And it kind of removes that opinionated, “I am going to put my function statement like this because I feel…” Python’s like, “No, you don’t get an opinion. My opinion is what’s going to happen here.”
Pekka Klärck:
But of course, then you still have like, how many spaces are you able to use? Like, [crosstalk 00:26:44] spaces or tabs, and are you going to have empty lines here, where, and all this kind of fight.
Josh Birk:
Okay. So on the framework itself, are there any features or anything on the roadmap coming up? You were talking about moving to Python 3. Anything in the future of Robot Framework that you want to give a shout out to?
Pekka Klärck:
Well, we are just now developing Robot Framework 4 which is going to be a really, really big release feature-wise. It’s going to have, for example, long-awaited skip status. So that’s one thing that now you can do, that you can skip a test case. Otherwise earlier it was either pass or fail and then we had our custom criticallity concept that allowed you to do among other things [crosstalk 00:27:30] skip function, but now we are going to get the real skip thing in. So that’s going to be big.
Pekka Klärck:
It’s going to have some enhancements related to type conversion we do with arguments. It’s going to have some enhancements to our library documentation related features, both to create the HTML document testing that we can generate for libraries. That’s going to be better and also we are going to create better so-called spec files for editors and other tools to use.
Pekka Klärck:
It’s going to also have a enhancement that hopefully make it easier to create better debuggers in the future. We have so-called listener API that gets notifications during execution, and there are certain important enhancements coming with that.
Pekka Klärck:
Finally, we just actually today made the decision that we tried to squeeze native [inaudible 00:28:31] structures into this release. They were planned for the next major release, but there’s quite a lot of demand for them so we try to get them into as well. Nowadays, when you create tests with Robot, you basically construct from givers, but then there are givers like run giver if that can execute things conditionally. But now we are going to add this native [inaudible 00:28:57] structure to Robot Framework to induct itself so that you can do things conditioned that if something happened due to something and in other place it will do something else. That’s especially important in this kind of business process or automation. There are needs for that also in test automation, but in RPM. So then that’s much more higher priority.
Josh Birk:
Got it.
Pekka Klärck:
So that kind of stuff is coming and it’s going to be really interesting and big release.
Josh Birk:
Cool.
Pekka Klärck:
We just got an alpha out this week with skip status. Hopefully we’ll get an alpha two out quite soon as well.
Josh Birk:
Cool.
Pekka Klärck:
Going to be also some backwards incremental changes there for do the skip steps, for example. That’s the reason why we want to have early alpha so everybody can adapt.
Josh Birk:
Got it. You had mentioned earlier that the pandemic had affected the conference cycle, which is happening to everybody. Has it affected development at all?
Pekka Klärck:
Not that much directly. We had since the Nokia days where we had anyway, pretty distributed way of working, so not [crosstalk 00:30:10] this work in the same place. We’re working with GitHub producing [inaudible 00:30:15] requests and so on. Now we actually have a bit bigger team as well, which is nice that we have more people working with this release than just me. Many of these are actually, some of these are physically pretty closely situated to me, but due to COVID, it’s not the best idea to meet that much. So that’s kind of annoying, but-
Josh Birk:
Got it. Gotcha.
Pekka Klärck:
Also like [inaudible 00:30:43] from chairman so we’re able to be meeting face to face that much anyway. Probably we would at some point. It hasn’t that much affected, but of course that we cannot organize the conference now in January means that we are not going to get money from that. That’s kind of a problem for the next year, but we’ll see how well the online edition works. I hope when we get more information about the visit, try to get a call for papers open relatively soon. I hope we get a lot of people in there and also that will hopefully bring some money for the foundation.
Josh Birk:
What was the original… When did you decide we need to have a conference on this? What was the motivation behind that?
Pekka Klärck:
There was a lot of people were asking about it and we noticed that, okay, we have community. I think it’s actually when so that we started running meetups around the world, but especially in Helsinki. When we had a meetup where we suddenly had 80 people in, I figured that okay, we need to start have a conference because 80 people would be already a decent conference. So I said, why not? That’s how basically it started. Then we run it and I think we had 250 or 300 or something like that in the first installment and then it’s been increasing a bit. So I think it was 350 or something like that last time, last January.
Josh Birk:
Got it.
Pekka Klärck:
It’s been nice. Being based in Helsinki of course it’s kind of far for people from US, but we have had I think every time like a dozen people from the States as well, and also around the world, so that’s been awesome. Of course, a lot of people from Finland, from Helsinki where it’s being organized. A lot of people from around Europe, which is obviously like two or three-hour plane flight away, compared to the US that is much, much more. So these are the people that participate.
Pekka Klärck:
The great thing with the online conference that we’re now planning to organize, we actually already have made a plan that we are going to do it. The great thing of course, now it’s easy for people around the world to participate.
Josh Birk:
Right, right.
Pekka Klärck:
Both as a presenter and also as participants. It’s going to be interesting to see when we open the CFP how many proposals we are going to get. I would expect we get even more than for the earlier on-site conferences.
Josh Birk:
Gotcha.
Pekka Klärck:
So that’s going to be great, and I think that if it goes at all well, we are going to keep running them even if we hopefully in the future sometime can also again organize an onsite event.
Josh Birk:
I very much sympathize with you on that and I wish you all the success with the virtual conference. I keep hearing that there’s that additional reach with the virtual conference, and like Jason was saying, Jason Lance was saying that about their opensource sprints, they’ve had to go virtual. They’re thinking about keeping a virtual layer on them even if they go back into real-life events. I also think Jason would thank you actually for having it in Helsinki in January, because apparently US flights to Helsinki in January are surprisingly cheap.
Josh Birk:
And that’s our show. Now, we will have links to both the Robot Framework and the Robot Framework Foundation in the show notes for this episode, if you would like to check them out. Now, before we go, I did ask after Pekka’s favorite non-technical hobby and it turns out, Finland’s really good for skiing.
Pekka Klärck:
Well, we live in southern Finland, so not big hills, but something. It’s fun. I’ve been doing even like park for little jumps and waves and stuff like that. So that’s okay. Small hills even, but then we have some decent opportunities if you go to north of Finland to Lapland. I especially like off-piste telemark skiing. That’s my really favorite. Then I have kids which is kind of [crosstalk 00:34:47] of the free time, so you don’t have that much problems like having extra hobbies.
Josh Birk:
I want to thank Pekka for the great conversation and information. And of course as always, I want to thank you for listening. Now, if you want to learn more about this show, head on over to developer.salesforce.com/podcast, where you can hear old episodes, see the show notes and links to your favorite podcast service. I’ll talk to you next week.