Selenium will continue working, and is actively supported by Mozilla. The IDE (the plugin that allowed UI-based recording of tests) is the only thing that's not working.
when the developers involved with Selenium suddenly decide to just drop a browser for one of their sub-projects then this might very well indicate a trend - even if it's just that firefox is less actively supported in future.
I understand where your concern is coming from, but I think you're missing a few of the pieces:
* When it comes to Selenium, Simon (the guy you replied to) is about as authoritative a voice as they come.
* The death of Selenium IDE is anything but sudden. It's really been more of a zombie for years and just kept kicking along. It's been saved from absolute death a few times over by generous support of volunteers willing to pick it up. But I don't think anyone tracking Selenium development is going to be surprised by this move.
* Selenium has been on a multi-year quest to shift support for the browser drivers out to the browser vendors by way of the WebDriver W3C standard [1]. The goal is for Selenium to be more of an interface to browser-specific implementations of the WebDriver specification more than anything else. Which is to say, Selenium dropping support for a particular browser shouldn't be too concerning because the major browser vendors will be maintaining their own driver implementation.
* Slightly related to the above point, but Selenium IDE is not and never has been maintained by Mozilla. The Firefox WebDriver implementation, however, is. And Mozilla is heavily involved in the editing and drafting of the WebDriver specification.
We knew this was coming down the track, but the selenium project lacked the people to prevent it from happening.
Sauce Labs donated Selenium Builder (nee Sauce Builder) to the project to try and help. Applitools have recently leant some engineering muscle to the problem. The problem breaks down into two main areas:
* Technical: the underpinnings have switched from the XPI model to Web Components. Mozilla are doing what they think is best for their browser, and I know that they make their choices with thought and data.
* People: every successful OSS project has a company or person acting as its champion. The selenium project has people working flat out for the language bindings, the w3c "WebDriver" spec, grid, and supporting the community. We lack a champion with the time to spend on IDE.
We can fix the technical side of things. The thing that we could really do help with is the people-side....
Always curious how moves like this help people who are actually doing stuff in the browser automation/testing scene (I am just a trend follower/leech off the work being done), glad to hear you guys were ready and props on thinking ahead.
I think that there are plenty of reasons for companies not to contribute. Not many companies have spare engineering capacity for working on OSS. Of those that do, they have to choose where to spend the effort --- testing tools aren't as exciting as Machine Learning, or the latest JS framework, or.... Of course, once you start hacking on the code, you may find you like it a lot. :)
The IDE is a mature, and old product too, so even if engineers can spend time hacking on it, getting up to speed can be tricky. The Selenium project has an active "selenium-developers" google group, a #selenium IRC channel on freenode, and a Slack channel, where many of the core team can be found.
Which is a long way of saying that it's not always easy for even motivated individuals and companies to contribute to OSS.
