 Hello everybody, how exciting is it to be here? I can't begin to describe how excited I am at least. Thank you all so very, very much for being here. It means an awful lot to me. Like Selenium is an open source project and we rely on people like you, our users, to come along and support and help. And quite often when we're on the mailing lists, the only things we ever see are people being unhappy or experiencing problems or filing bugs and that's brilliant. But it stays like this that it reminds you that actually people get so much utility and so much use out of the work that we're doing as a project and just makes you smile really, really broadly. So this is the fourth Selenium conference, Selenium 2014. The first one that we had was held in San Francisco and it was exciting, right? We'd never put on a conference together. We never thought that actually we had this thing that people would pay money to go to a conference for. Like just totally blew our minds. And we really enjoyed Selenium and about 300, 350 people that came to that. The next year what we did is we went to London, my home city. Love London an awful lot. That was a huge amount of fun as well. We got all the committees together. We got this huge user community and we had a while of the time. The next year was meant to be in New York except we're not very good at being organized. We're quite good at writing software, not very good at being organized. And by the time we got around to arranging everything we found out that it was way too much to book where we wanted to be in New York. So what we did, we went north up the American coast a little bit and we ended up in Boston. And Selenium come from Boston, again a huge amount of fun. And now we're in Bangalore. Now, why did we pick Bangalore? Like we've done the US, the UK, the US. If you took a look at where we have the largest number of users of Selenium. If you looked at where people are really using our product what happened was there was a huge community over in the West Coast and Silicon Valley. There's a large European community and London is a really accessible place in Europe so it's easy for people to get to. On the East Coast there are a large number of Selenium users. And when we were planning this conference what we were thinking is where is the largest pool of Selenium users that haven't yet had an opportunity to attend a conference. And I felt quite passionately and so did many of the other people on the organizing committee that Bangalore was a really fantastic place to do that. So we're here because of you. Thank you very much for enthusiastically using the product and thank you very, very much for hosting us in this city. Of course, we've now run out of all the easy places to hold Selenium conference. So I'm not quite sure where Selenium Conference 2015 is going to be held. If you've got any ideas what we'll be doing we'll be kicking off a conversation on the Selenium users and the WebDriver mailing lists. So feel free to sort of chip in with bright ideas and suggestions. The thing that really helps is if there's somebody on the ground who can help us organize it. It would be quite nice to go back to the Americas maybe North America, maybe South America who knows but anywhere that's a good idea that will help us organize we will certainly think about and we'll consider it and we will announce Selenium Conference 2015 when we're ready. Safe and source right, you do things when you're ready. In case you're wondering why I'm up here and I'm talking to you, I'm Simon Stewart. I'm the current lead of the Selenium project. I'm the creator of WebDriver and I'm the co-editor of the W3C specification. And like I never thought in 2006, 2007 when I started writing WebDriver that I'd be talking to like 350 people, 400 people in a room, it's mind blowing. So wow, thank you guys. So we are an open source project, right? We got into writing Selenium because we had in the classic sort of way that they phrase things in the open source world and itched to scratch, we had a problem to solve. And that's still how I think about what I do every day. Like when I contribute to the Selenium project, the thing I'm doing is I'm working on the problems that I'm running into and that I know the people around me are running into. And that's how many of the people on the project work. And that means that one of the ways that we measure success isn't by comparing ourselves with other people and other projects, it's how happy we make ourselves and how happy we make our users. Like if you define success by other people, you're always going to be unhappy, right? Having said that, it is incredibly pleasing that Selenium is still a market leading product. I looked on monster.com before I came out here and there were two to three times more jobs for Selenium users than there were for QTP. And like wow, how on earth did we end up in this situation? I also have to say while I'm up here saying thank you because we're a market leader because of you guys. Thanks to everyone who helped make today happen. Obviously agile facts have helped host this with Nuresh. Nuresh, if you're around, can you just raise your hand and take a bow? Or if you're not around, don't do that, excellent. And the Software Freedom Conservancy. The Software Freedom Conservancy are the foundation that hosts the Selenium project. They've provided us with a lot of support over the years since we joined them. And it's always nice to say thank you to the people who help you. And also thank you to the people with the commit bit. There are a handful of them in this room. Andreas, who would be here, I think is feeling currently unwell, but he should be here later on. If anyone else with the commit bit would just like to stand up so people know who you are. There we go. They're the guys that helped make this project tick along. I'm really pleased that some of them have made it here. So yes, this is Selenium 2014. We held one a year ago in 2013 in Boston. What was the state of the world back there? Well, one of the things that really stood out was that there were browser vendors who owned their own implementations. And at the time, those were Opera and Chrome. Those were the two main implementations that were supported by the browser vendor. Fast forward to today, and it's a completely different world. Opera and Chrome are still supporting their drivers. If you have the IE developer channel, pardon me, if you have the IE developer channel, you also have web driver support provided by Microsoft, which is like, wow, who thought that would ever happen? If you've got an Android phone running KitKat, in KitKat, the Android web views are powered by Chromium. That's the open source version of Chrome. And if you've got the developer setting set and the debug flags enabled and blah, blah, blah, and rah, rah, rah, you can control your KitKat phone's web views using web driver. They've baked that into the product. And also, I know we don't really think about it very often these days, but Blackberry are still out there. They still have a really nice mobile operating system, and they support web driver as well. They came to the last W3C, at the face-to-face meeting for the W3C, was really pleasing to see them. Of course, you know, we're here in India. It's an emerging market that the world has these. And not everyone can afford the sort of high-end phones that sort of the Android devices the iPhone offers. Mozilla are doing their best to supply a low-cost phone, a low-cost operating system that works really well. And they do that in the form of Firefox OS. And as part of the Firefox OS development, Mozilla have been working on a framework called Marionette. Marionette is their implementation of web driver. Now, the interesting thing with Marionette is because it's baked into Mozilla, into Firefox as a product, into Firefox OS, it's also making it into their desktop product. And so, in the not-too-distant future, fingers crossed, touch wood, Marionette will eventually ship in desktop Firefox and be available for everyone to use. So, we're in a world where we've gone from two vendors supporting the product officially with their own drivers to a world where a majority of the vendors are now supporting their own implementation. And that's a trend that's going to increase over time. So, bizarrely, the Selenium project, as we know and love it, is going to become smaller and smaller because the bulk of the code that's in there right now is to support the drivers for the different vendors and those implementations are going to fade away as the vendor implementations come up. I'm really excited about that. Having said that, in the past year since Selenium come 2013, there have been over 1,300 commits. That's an absolutely astonishing amount of code. That's more than two or three a day, which for a project of this maturity, we originally shipped code in 2006. It's astonishing. There have also been lots of bugs filed. Some of those bugs are fantastic. Some of them are of dubious quality and some of them are tremendously popular. I'm pleased to announce here that issue number 141, HTTP status codes, still marked as won't fix. Just not touching it, not going to happen. If you've been following the Selenium project, that's an in-joke. We marked it as won't fix about three years ago and it's this perennial debate that kicks off. If you ever want to see what a hilarious bug looks like, that's the one to go look at. So, the future, right? Selenium conference, all about today and what's going on. It's a chance for you to meet, get to know each other. It's also a chance to hear about how people are using the product and it's also an opportunity for you to hear where we're going in the world, in the future. So, I started working on Selenium project by accident. I had been working in a company called ThoughtWorks and I'd written this sort of shim over one of the Java frameworks that were available at the time. And I'd done that four or five times and eventually ThoughtWorks had a quiet spell. They put me on what they call the beach. Other consulting firms call it the bench. It's where you're sort of between gigs, right? And you can get on with something interesting. It's like, I tell you what, I've done this wrapper for these HTTP, these browser emulators just so many times and it's a waste of time. It's a waste of effort. Tell you what I'll do. I'll just put a nice skin over the top of it one last time. I'll make that open source, which I did in consultation with ThoughtWorks. I'll make that open source and then I'll never have to write it again. And that means that in two months' time I can relax. This was the middle of 2006. Third of January, 2007, I pushed the first code for WebDriver Live. I was already running slightly behind schedule but I was fairly confident that it was almost done. In July, 2011, we flipped the switch on Selenium 2.0. Selenium 2.0 was the marriage of the original Selenium project and WebDriver. Jason Huggins and myself had got together, had a series of interesting conversations and decided that actually there was a future direction for the project and that future direction was the WebDriver and Selenium to collaborate. So we shipped Selenium 2.0. The major feature in that was Selenium WebDriver, the APIs that I hope you're all using now. And that was a long time ago. That was 2011, three years ago. There aren't many projects that are three years old and still going, right? So we're looking forward, right? We promised Selenium 3.0 at the last Selenium conference and spectacularly failed to miss the deadline of Christmas, which we optimistically set for ourselves. I noticed actually before this began that they were playing some Christmas songs, so I assumed someone picking the music knew what we were planning to do at the time. But yes, we need to move forward. So Selenium 3.0. The reason why we missed our Christmas deadline is because Selenium 3.0, as planned, was going to be two separate features. The first one was going to be the end of life of Selenium RC and the second feature was W3C compliance. I'll talk about the spec in a little bit, but we are running behind schedule with that. And so it's time to sort of reassess what it is that we want in Selenium 3.0. The plan right now for Selenium 3.0, which should ship in the not too distant future, but it might be a few months, you know us, we're open source, we're not very good at actually predicting when we're going to do things. But the plan for 3.0 is that we're going to remove Selenium RC. If you're using the original RC interfaces, it's time to finish migrating your code. In the next Selenium 2.0 release, 2.0 release, we are going to be marking the Selenium interfaces as deprecated in all the languages that support that feature. You can, however, still use the WebDriver APIs. They are still fully supported, and they are the things that are going to remain in the project moving forward. When we ship Selenium 3.0, what we will be doing is we'll be hiving off the current Selenium RC implementations, Selenium core implementations, and providing them as a standalone jar that you can download in addition to the existing 3.0. At that point, we will no longer be making bug fixes, and we will no longer be taking contributions to move Selenium RC forwards. The reason for this is that we're an open source project. People are working on the things that they're really passionate about, and they're interested about. And for the last couple of years, no one seems to have been interested or passionate about Selenium RC. That code is now foreign to a lot of the developers who are working on the project, and we're not comfortable with that sitting there and gradually rotting. It would be far better for us and for our users if we officially announced, yes, this isn't properly supported. The thing that is supported is here. It's a Selenium WebDriver APIs. By the way, who is still using the original Selenium RC? Okay, so for those of you watching on the video, there's approximately 400 people in here, not one person raised their hands. That's astonishing and brilliant, and maybe we should have released 3.0 a lot sooner. For those of you watching on the video, by the way, if you haven't started the migration to WebDriver, it's a really good idea to start now. Jason Labor did a really interesting keynote in London where he described the process that Google went through to get there. It's hard, but it's not impossible. So I said that I was going to talk about the specification. The W3C specification is an interesting beast. Are you aware, by the way, that Selenium is going through W3C standardization? There are a few shakes of their heads, there are a few nods. So the W3C, the World Wide Web Consortium, are the home to a series of standards, such as HTML, you may have heard of it, XML, SVG. They're the standards that make the browsers interoperate and work well together, CSS, another thing that's there. And one of the things that we noticed and opera encouraged the Selenium project to do was that we were finding it harder and harder and harder to implement the features that people wanted in WebDriver and Selenium. And the reason for that is that browsers were becoming increasingly sophisticated. They were offering advanced things such as the Shadow DOM, enhanced JavaScript, faster engines, HTML5, all that stuff. And Selenium had started in the sort of Web 1.0 era, where beautiful layouts were done using tables. And CSS was a dirty word because it would crash whichever browser it was that you were attempting to use it in. The world has changed since then. And we were finding it harder and harder to hit the fidelity of user emulation and the control that people needed. And the only reason why we're able to do half the things we're able to do at the moment is because we're so deeply entwined with the bounds of the browser. Selenium WebDriver is implemented on a per-browser basis and it works by integrating tightly. The IE driver, for example, rather than being written in JavaScript like the original Selenium RC implementation, is written in C++ and wraps the series of COM objects that form Internet Explorer. The Firefox driver, again, written in XP-COM, the language in which Firefox itself is implemented and so on and so forth. But we're not in the browser vendors, right? We're open source developers. And it's quite hard to sometimes find the hooks and the places where you need to go. And so the future of supporting developers, users, people like you is going to be, if the browsers that we're using have implemented the automation interfaces that we use. The only way that you can get the browser vendors to support that level of automation is to standardize it. So we're going through the W3C, the World Wide Web Consortium, and we're working on that specification. I say working. At the moment, David Burns is probably the most active contributor to the W3C standard. He works at Mozilla. He can't be with us today. He's in the UK, but I'm sure he's sent his love. And things are going a bit more slowly than we expected it to. Hopefully, fingers crossed, we're going to move it forward. We keep on having plans to just limit the scope of what we're working on because feature creep kills projects, right? The more features you add, the harder it gets to move forward. And so we're going to continue focusing hard on that. And hopefully we're going to see some progress. We will be announcing when we go to last call, which is the final step before recommendation on the mailing lists. If there's things you want, if you'd like to contribute, we are on the W3C GitHub repose. So you can just come in, grab the code, take a look at the text, correct typos, contribute fixes, things like that. More than welcome to. We would love that. The specification itself is an interesting one. The W3C normally does specifications around language bindings, around features that browsers should implement. The WebDriver spec is around a protocol, protocol running over HTTP and using JSON. And the reason why we picked those ages and ages ago was because every language has HTTP and JSON support. And so you can implement client bindings in any language we want. In specification, we talk about local and remote ends. The local end is where your test is. It's the language you're writing your test in. And the remote end is the Selenium server or the implementation that a browser vendor ships. And the browser vendors have been really good about providing an implementation of the remote end that speaks this wire protocol. And that's the thing that allows interoperability and allows us to extend the grids that you have and just drop in a new browser implementation without having to necessarily rewrite all your tests. The W3C standard, when it ships, will introduce some changes to that wire protocol that we currently use in 2.0. And then we're enhancing for the W3C. The main one is that some of the fields that used to be numbers now become strings. And some of the URL endpoints disappear or change or their meaning is altered slightly. And because of this, you can't currently use a Selenium 2.0 client or a 3.0 client with a W3C compliant server. Selenium 4.0, when we finally get around to releasing the W3C specification, we will also be releasing Selenium 4.0. The last few releases of Selenium 3.0 will be forward and backward compatible. That is, they will work with both the existing Selenium servers and with the W3C compliant versions. When we ship 4.0, that first 4.0 release will maintain that compatibility. And then we shall drop backward compatibility. So from 4.0 onwards, we'll be speaking the W3C protocol and we will be W3C compliant on the language bindings. That's gonna be really important for you. Hopefully, if you keep up to date, if you just follow what's going on, it will be a drop-in replacement for you. You won't notice that we've completely changed the plumbing from underneath you because you're all using the APIs rather than the raw wire protocol. That also leaves us with the question of what to do with Selenium IDE. How many of you in this room use Selenium IDE, the record playback tool? Okay, there's a handful of hands. Is that the correct collective now? I never know these things. Who knows? So yeah, Selenium IDE is growing long on the tooth. It was based on the original technology that Selenium RC and Selenium Core were based on. And it is very tightly tied to Firefox. One of the things we hear on a regular basis is it would be really nice if you could use Selenium IDE in a browser that isn't Firefox. A while ago, Source Labs kindly donated the Selenium Builder project, the source builder at the time is the name of the project, to the Selenium project. We haven't done much with it, but the plan is in the 4.0 lifetime, we'll be switching from Selenium IDE to Builder and removing the old Builder code because it's increasing long on the tooth and we want something that's fit for purpose and it's gonna work for you. If you are interested and motivated and would like to help that effort, please do get in touch. A lot of the core developers on the Selenium project are very interested in the browser implementations and the language bindings. And we could really do with somebody who is enthusiastic about helping us improve the IDE experience because we know that there are a significant number of people out there who really enjoy the record playback, who need the record playback because they lack the experience to write all the code themselves. Also, this is a plea for help. Our documentation could really do with a shot in the arm. If you use Selenium, if you've run into problems and if you have a way of, if you can articulate yourself clearly in a way that I'm clearly not doing right now, we would love some help improving our documentation. Please get in touch with the project, help us move that forward. It's open source, we wouldn't be here if it weren't for you. So we've talked a little bit about the future of the project. Selenium 3, where we end of life, Selenium RC and the original implementations of Selenium Core. Selenium 4, where we move to W3C compliance. But the interesting thing is that we've only been talking about the desktop browsers. The desktop browsers are a huge part of the market, but they're not the only part of the market. Hands up, who's got a mobile phone with a browser on in their pocket right now. Lots and lots of people. If I'd asked that question in 2005, maybe a few people with like a Nokia navigator or something would have raised their hands and people would have looked at them and gone like, but how, it's so painful. WAP was a thing back in the day, right? So mobile is massive. Mobile is becoming more and more and more important. I used to work at Google. And while I was there at Google, I was working on their browser tools and automation group in that team. And one of the guys from the Tokyo office came up to me, he goes, I've got a crazy idea. And I was like, what's your crazy idea? And he goes, web driver. And I go, yes. And he goes, web driver for a mobile phone. It's like, oh, well, we support the web views. He goes, no, no, no, no, no. Not for web views, for mobile phones, for Android, for iOS, where you can control the native interface. I thought he was insane. It was the weirdest thing I'd ever heard. But I'm an open-minded commudgeon at the best of times. And he persisted and he was explaining to me that, well, think about it. The web driver API is an API for moving across a tree. And you can navigate through a tree and you find nodes in that tree, and then you can interact with those trees. So the web driver interface, the find element, allows you to navigate through the tree. The web element represents a node and allows you to form interactions. I was like, okay, I see that. And he goes, well, how do you think a UI on a mobile phone works? It's a tree and it contains nodes and you can interact with them. I went, that's still crazy, right? I couldn't quite see how it was all gonna work. And so he invited me to Tokyo and I went to Tokyo and I sat with his team and they wrote some code, which they called native driver. If you go to Google code right now, you can go to nativedriver.googlecode.com. They open sourced that and it blew my mind, right? I had no idea that this was possible. I had no idea it was a good idea and I had no idea that somebody could make it work. Sadly, because of the internal reorganizations that happened at Google and the way that people move from team to team, native driver ran out of steam and never really took off. And that was sad because it was very clear that mobile is the future of the web, right? We are increasingly being asked to automate products on mobile phones. They might be pure web views, in which case, web driver as it stands on Android, for example, using the Chromium web views would be sufficient. But they're sometimes native apps and they're quite frequently hybrid apps where you've got part native, part web post. And that's a complex thing to do. And so I was quite sad when I saw a native driver run out of steam. I was very, very pleased when I saw three projects sort of arise that took that mantle and moved it forward. The most popular of these projects right now is Appium, which was backed by Source Labs. Appium hit 1.0 in the not too distant past and they're continuing to move forward. They support iOS and they support Android. The project that I've been contributing to a little bit is Cell Android. So Cell Android is an implementation of the web driver protocol for Android phones. And there's iOS Driver, which is originally by Francois Reynard from eBay, but is now worked on by a group of people, including people from Facebook. It's quite exciting to see that happen. Now one of the problems that we have is that testing on mobile phones, mobile testing using the web driver APIs, is very much like how we used to be back in the day on web driver. The early web driver implementations, there was something completely separate written for each browser. And what would happen is someone would report a bug and there'd be incompatibility in usages, right? So it would work in Firefox, it wouldn't work in IE, so on and so forth. We spend a lot of time and effort standardizing how we would are going to deal with problems and give you a consistent experience. And one of the things that we really want people to be able to do is if they're testing on iOS or if they're testing on Android, to be able to take an implementation of a mobile web driver version, be it Cell Android or Appium or iOS Driver in Appium, and drop that implementation in and not have to rewrite their tests. There might be a few changes because different products have different features and different ways of doing things. But it's not enough to just go to be wedded to a product and be unable to move away. One of the nice things that you have with the web driver interfaces is that level of abstraction, right? So what's happening slowly but surely is the authors of these three tools, Appium, Cell Android, iOS Driver, are collaborating together in a subproject on the Selenium Google Code page. And they're working on a mobile web driver specification. And the idea is that everyone contributes to that, everyone agrees on that, and you have consistent behavior between the different implementations. And so you have choice. And so you have the ability to pick the product that's best for you. Hopefully at some point, what we will do is we will take that specification, that mobile specification, and roll that into the W3C, which is going to be fun and interesting and exciting times. So yes, those are the big themes of the future of Selenium. We have the end of life of RC. That's going to be really important, right? I'm really, really pleased that almost no one raised their hand, no one raised their hand to be using Selenium RC. Because we've been quite nervous about pulling the plug on that because we know that people have made a huge investment in their tests, and what we don't want to do is cause everyone to have to throw away a huge amount of work. And that's why there's going to be a compatibility shim that will allow you to use a web driver back to Selenium. So Selenium 3.0 is coming. Selenium 4.0, where we finally hit W3C compliance, where we finally ship that W3C specification, and hopefully all the browser vendors get on board and do their own implementations. And mobile. The mobile web is going to be enormous, it's going to be big, it's going to be important. It's going to be an exciting time, I think, for all of us. And so we're here. We have Selenium conference. There's going to be a bunch of interesting talks, there's going to be an opportunity for you to interact with the people around you, communicate, get to know each other. I strongly advise that one of the nicest things at a conference is, first of all, the presentations, the interesting talks, but also the conversations and the friends who make the connections you have. So if you have an opportunity to meet someone new, say hello, be nice to each other. It's going to be a way of building the community. And I have to say, I know I'm scheduled to speak for an hour, but actually I'm so overwhelmed, I'm so excited to be here, that I just want to get on with my day. So I'm going to stop here and not try and pad out an extra 45 minutes, 30 minutes, 15 minutes of content. Thank you all very much for being here. I hope you have a fantastic conference and I hope you really enjoy yourselves. I'll be around, feel free to approach me and ask any questions you need to. Committees are here and please do talk to each other. Thank you all very much for being here.