should 'selenium' become 'apache' or 'eclipse'? (or did it already and i wasn't paying attention)

[Adam Goucher]

Patrick suggested on irc yesterday, perhaps in snark, that there should
be a 'what is selenium' thread which I think is valuable and would
clarify things like bringing Se-Builder into the fold.

So.

'What is Selenium?'

I'll put forward two near-opposite spectrum answers.

1) A project which is responsible for the reference implementation of
the W3C WebDriver spec in 4 languages (Java, C#, Python, Ruby) as well
as the browser implementations for vendors who have yet to step to the
plate.

2) An umbrella project like Apache or Eclipse where OSS projects that
deal with Open Source Automation can leverage the shared resources of
the project. Certain criteria met, etc. like licensing under Apache 2,
donation of all IP to SFC, etc. Se-Builder, sure! Sikuli (if they
wanted), sure! Py.Saunter, sure! FlynnID (if they wanted), sure! (In
other words, OpenQA v2) [Bound my license and IP rather than repo for
those who don't want to get sucked into Google Code and CrazyFun)]

I thought, from both the external appearances/behavior of the project as
well as where any/all development was occurring that it was 1. The
enthusiasm for including Se-Builder into the fold (from people that
don't recommend using record-and-playback tools...) makes me think it is
more option 2 in desire.

This I think is a /big deal/ and dramatically affects how we
market/brand, how I suspect it should be governed/organized, etc. Lean
on the spectrum towards choice 1 and Se-Builder doesn't fit (nor does
Se-IDE really). Lean more towards 2 and suddenly money becomes an issue
as build farms need to be built (and maintained), community by-laws,
governance, etc. becomes important -- both Eclipse and Apache have
full-time IT staff to deal with this.

(If I'm confused, you can bet that the casual observer has no freaking
chance of understanding.)

-adam

[David Burns]

1) A project which is responsible for the reference implementation of the W3C WebDriver spec in 4 languages (Java, C#, Python, Ruby) as well as the browser implementations for vendors who have yet to step to the plate.

Thats what we are. We can expand the languages if we can get the right contributors involved and with some discussion.


Carrying this over from Py.Saunter's ask for inclusion...


On 2012-11-23 9:09 AM, David Burns wrote:

The reason why Se-Builder should be included in Selenium in my opinion is that its solving the multiple browser issue that Selenium IDE can't solve. The web is more than one browser! If we want to be able to push forward being able to work cross-platform cross-browser, especially for people getting into automation then Se-Builder gets us that. We may need to do education on when to use what tool but that is an education problem not a tools problem.

'Education vs Tools' is kinda strawman-ish.

Not really! We can give people a fishing rod and they might figure out how to fish. If we give them more info then we can show them how they can build meaningful things around it and can do more. E.g. Py.Saunter is a good example of adding a net to your fishing rod to increase your ability but it does not change the fact you need the fishing rod to get started.

I know that you are gunning for some form of governance talk here so let's get it started. At the moment I only have three main questions

I think the 'should selenium become apache or eclipse' thread I think for a potentially better articulation of [some] of my concerns.


No, I dont think we should even entertain the idea. When we have pushed all the browser specific code to vendors what will be left? Just the language bindings. By pushing the browser specific stuff to vendors we are kind of slowly putting ourselves out of business but at the same time giving ourselves a living legacy part of all browsers!

How does Py.Saunter give us cross-browser/cross-platform support that the currently python bindings don't?

Does this solve a real problem that perhaps the Selenium Developers should look at in terms of BROWSER AUTOMATION or is it solving a deployment/authoring issue?

Its the 'getting started' problem that it solves. I have seen too many teams flail and have to backtrack and re-do work because they don't even know the right questions to ask let alone to consider. Export from Se-IDE/Se-Builder ... code away ... rework to page objects. WebDriver ... want to you Cloud/Grid ... rework to Remote. Which should be easy if it was abstracted, but they don't know to do that. You might say that this is a documentation problem, but if the documentation says 'in order to start using this in a means known to work you need all these /other/ components and worry about all this /other/ plumbing before' then thats not really solving a problem.

As currently un-consituted, there is /no/ distinction in the project between BROWSER AUTOMATION as you put it and deployment/authoring.

So I consider this not a browser automation issue and an authoring issue. Perhaps we can revisit later but this is pure innovating on top of our bindings to help your authoring of tests.

You have previously stopped being the maintainer of a tool due to work commitments but said you will support Py.Saunter. Will support be short/long term?

I suspect I would have found time to continue working on Se-IDE if it wasn't for the fact the irony of working on a tool that I expressly told people to uninstall and forget was not getting too great and distracting from helping people success rather than aiming a shotgun at their feet for them. Again, with the buckets of my own biases, when I teach Se the first thing we do is uninstall Se-IDE, it gets the in way of being able to succeed. Teams make headway when they forget it exists. (Actually, its second -- getting rid of Eclipse is first...)

And this is the right approach but approach this as someone who isnt in an area where you teach or has regular Se meetups. Having the right documentation as well as the having something like "use strict" that is turned on can get around that.

David Burns
URL: http://www.theautomatedtester.co.uk/

-adam

--

[Patrick Lightbody]

On Nov 23, 2012, at 8:06 AM, David Burns <david...@theautomatedtester.co.uk> wrote:

1) A project which is responsible for the reference implementation of the W3C WebDriver spec in 4 languages (Java, C#, Python, Ruby) as well as the browser implementations for vendors who have yet to step to the plate.

Thats what we are. We can expand the languages if we can get the right contributors involved and with some discussion.

David,

I have to respectfully disagree. That may be what has received the majority of your focus and Simon's focus as of late, but Selenium was from the start a collection of multiple projects (IDE, Core, RC, and Grid) designed to cater to a broad set of users who needed various forms of browser automation.

As I said in another thread, I'd like to continue that tradition. I believe that if we are simply a vehicle for driving the W3C spec we are underachieving.

Patrick

[David Burns]

If we have a look at what we have been working on in the last year then that is all we have been doing. Perhaps we are under-achieving but then we should do what we can with the resources we have.


Core has been deprecated as a product. RC is in maintenance mode and when we really start the technical changes for WebDriver, agreed in the W3C meeting in Lyon in October, then RC will more than likely be deprecated because of breaking changes to WebDriver. Since Grid is really part of the remote server architecture its not really its own product, like it used to be in the past. This leaves IDE as a separate product but from a casual observer it doesn't have active maintainers so folding SeBuilder in makes sense and just stop IDE.

So we are down to the Java RemoteWebDriver Server and IDE and language bindings when the W3C stuff is done. This is the way that things have been going for the last couple of years. But... Let's entertain the idea of Selenium as a foundation of products. This leads to questions.

1) Apache has a group of directors that are voted in. We should do the same then.
2) When people stand for the directors position, what is the criteria for standing? Should they have committed, more than a token commit, in the last year? This is very different to what currently happens
3) How would we get money? (I know of an email about this to other committers but wasn't part of the mailing list so have no idea where it went)
4) How do we stop the "It's gone to apache therefore its a dying project" mentality happening to our group?
5) If a project gets folded in and the developers walkaway what do we do?
6) Should we move our code off Google Code to our own servers that have source control on them since it should be neutral?

David

David Burns
URL: http://www.theautomatedtester.co.uk/

--
 
 

[Simon Stewart]

Hi,

TL;DR: Selenium is a brand, with several projects.

Tedious long version: 

I've read the other entries in this thread, but thought I'd weigh in here, because my answer involves time travel, and it seems appropriate to begin by zipping back in time to be the first poster :)

Back in the day, there was just "Selenium". And lo, the people saw it, and saw that it was good and rejoiced. But, verily, there was consternation amongst the tribe of developers, who rightly quaked in fear as they saw "tests" were just HTML tables. The tribe of developers thus took it upon themselves, and begat a wondrous device that allowed members of the tribe to control "Selenium" from afar. And the tribe of developers quoth "Look upon our work! It is mighty! And it is named "Selenium Remote Control" and the wire protocol is called "Selenese"

And that's where things started getting messy. 

Nowadays, the thing that was called "Selenium" is now called "Core", except by some people, who call it "Selenium". The original wire protocol is never referred to by name, but "Selenese" is often taken to be the table layout that is "Core", or "Selenium". We have "IDE", which I've frequently heard of as "Selenium", and "WebDriver", which is _also_ called "Selenium", "Selenium 2" or, on one very confusing occasion "Selenium RC". Of course, it goes without saying that RC is also called Selenium.

This was basically the state of affairs when we merged the selenium and webdriver projects. We never got very far clearing things up, but the agreement we had back then, and which I still stand by, is that "Selenium" is an umbrella term for a host of related projects. Thus, the correct names for the tools are "Selenium IDE", "Selenium Core", "Selenium RC" and "Selenium WebDriver". I think of it as a brand.

Right now, that brand is focused on browser automation. Case "2" is too broad in that case. The projects currently using the Selenium brand are closely related and share a common lineage, with the exception of WebDriver, which was just that: an exception. The brand is a strong one, and we have a sane and thoughtful approach --- though very seldom articulated approach --- to evolving the pieces that share the same niche (eg: we've been pretty clear around the messaging of "should you use RC or WebDriver?" and "How do I maintain my existing investment in RC tests in a WebDriven world?") Dragging in other projects that occupy the same niches as existing tools within the brand adds to user confusion, but we do so when there are compelling advantages.

This is a really long way of saying that I think Adam's initial spectrum doesn't actually include what we really are: a brand with a number of projects. One of those projects is the reference implementation of the of the WebDriver W3C spec (increasingly, I note, of the client side of that spec) We joined the SFC in order to deal with the "political" aspects of the projects that fall beyond our normal experience: things like fund raising, IP issues and legal matters. They've been doing a great job with that.

Does that help?

Simon

-adam

--

[Kevin Menard]

While I agree that's where the effort has been expended, both as a result of necessity and limited resources, I think Selenium should be more.  As more browser vendors take over their own implementations, too, we're all going to need something to work on :-)

Slight rant here, but I think overall the state of Web testing is terrible.  Very little has changed since the original release of Selenium, both with the project and with the industry as a whole.  I mean, we obviously have a much better tool now but it mostly does the same thing.  When Selenium first came out, however, that marked a major shift in how we all tested Web sites.  We have some very smart people on the project and in the community.  We could define what the next stage of Web testing is and have projects to experiment with and support some those ideas.  We could work to broaden who does testing and in what capacity (and incidentally, this is one big reason I'm in favor of IDE).

I guess that's overly broad, perhaps to the point of being trite.  But, that's what excites me.  Working on the Selenium codebase is sometimes fun and all, but it's a means to an end.

--
Kevin

David Burns

Monday, November 26, 2012 6:20 AM

If we have a look at what we have been working on in the last year then that is all we have been doing. Perhaps we are under-achieving but then we should do what we can with the resources we have.


Core has been deprecated as a product. RC is in maintenance mode and when we really start the technical changes for WebDriver, agreed in the W3C meeting in Lyon in October, then RC will more than likely be deprecated because of breaking changes to WebDriver. Since Grid is really part of the remote server architecture its not really its own product, like it used to be in the past. This leaves IDE as a separate product but from a casual observer it doesn't have active maintainers so folding SeBuilder in makes sense and just stop IDE.

So we are down to the Java RemoteWebDriver Server and IDE and language bindings when the W3C stuff is done. This is the way that things have been going for the last couple of years. But... Let's entertain the idea of Selenium as a foundation of products. This leads to questions.

1) Apache has a group of directors that are voted in. We should do the same then.
2) When people stand for the directors position, what is the criteria for standing? Should they have committed, more than a token commit, in the last year? This is very different to what currently happens
3) How would we get money? (I know of an email about this to other committers but wasn't part of the mailing list so have no idea where it went)
4) How do we stop the "It's gone to apache therefore its a dying project" mentality happening to our group?
5) If a project gets folded in and the developers walkaway what do we do?
6) Should we move our code off Google Code to our own servers that have source control on them since it should be neutral?

David



David Burns
URL: http://www.theautomatedtester.co.uk/

--
 
 

Patrick Lightbody

Sunday, November 25, 2012 9:06 PM

David,

I have to respectfully disagree. That may be what has received the majority of your focus and Simon's focus as of late, but Selenium was from the start a collection of multiple projects (IDE, Core, RC, and Grid) designed to cater to a broad set of users who needed various forms of browser automation.

As I said in another thread, I'd like to continue that tradition. I believe that if we are simply a vehicle for driving the W3C spec we are underachieving.

Patrick

--
 
 

David Burns

Friday, November 23, 2012 11:06 AM

1) A project which is responsible for the reference implementation of the W3C WebDriver spec in 4 languages (Java, C#, Python, Ruby) as well as the browser implementations for vendors who have yet to step to the plate.

Thats what we are. We can expand the languages if we can get the right contributors involved and with some discussion.

Carrying this over from Py.Saunter's ask for inclusion...


On 2012-11-23 9:09 AM, David Burns wrote:

'Education vs Tools' is kinda strawman-ish.

Not really! We can give people a fishing rod and they might figure out how to fish. If we give them more info then we can show them how they can build meaningful things around it and can do more. E.g. Py.Saunter is a good example of adding a net to your fishing rod to increase your ability but it does not change the fact you need the fishing rod to get started.

I think the 'should selenium become apache or eclipse' thread I think for a potentially better articulation of [some] of my concerns.


No, I dont think we should even entertain the idea. When we have pushed all the browser specific code to vendors what will be left? Just the language bindings. By pushing the browser specific stuff to vendors we are kind of slowly putting ourselves out of business but at the same time giving ourselves a living legacy part of all browsers!

Its the 'getting started' problem that it solves. I have seen too many teams flail and have to backtrack and re-do work because they don't even know the right questions to ask let alone to consider. Export from Se-IDE/Se-Builder ... code away ... rework to page objects. WebDriver ... want to you Cloud/Grid ... rework to Remote. Which should be easy if it was abstracted, but they don't know to do that. You might say that this is a documentation problem, but if the documentation says 'in order to start using this in a means known to work you need all these /other/ components and worry about all this /other/ plumbing before' then thats not really solving a problem.

As currently un-consituted, there is /no/ distinction in the project between BROWSER AUTOMATION as you put it and deployment/authoring.

So I consider this not a browser automation issue and an authoring issue. Perhaps we can revisit later but this is pure innovating on top of our bindings to help your authoring of tests.

I suspect I would have found time to continue working on Se-IDE if it wasn't for the fact the irony of working on a tool that I expressly told people to uninstall and forget was not getting too great and distracting from helping people success rather than aiming a shotgun at their feet for them. Again, with the buckets of my own biases, when I teach Se the first thing we do is uninstall Se-IDE, it gets the in way of being able to succeed. Teams make headway when they forget it exists. (Actually, its second -- getting rid of Eclipse is first...)

And this is the right approach but approach this as someone who isnt in an area where you teach or has regular Se meetups. Having the right documentation as well as the having something like "use strict" that is turned on can get around that.

David Burns
URL: http://www.theautomatedtester.co.uk/

--
 
 

Adam Goucher

Thursday, November 22, 2012 8:08 AM

Patrick suggested on irc yesterday, perhaps in snark, that there should be a 'what is selenium' thread which I think is valuable and would clarify things like bringing Se-Builder into the fold.

So.

'What is Selenium?'

I'll put forward two near-opposite spectrum answers.

1) A project which is responsible for the reference implementation of the W3C WebDriver spec in 4 languages (Java, C#, Python, Ruby) as well as the browser implementations for vendors who have yet to step to the plate.

[Simon Stewart]

It should go without saying that The Next Big Thing is mobile testing. I'll say it anyway. Both Jason and I have been circling the problem in our own ways. There's a missing fourth project:

4) Selenium Mobile, making it easy to test hybrid apps on popular mobile OSs

I suspect that the firebrand leading that effort will end up assuming the mantle of project lead at some point. I don't see that person yet. I'm not even sure that whatever will be "Selenium Mobile" is even out yet, though there are some interesting projects out there. The thing I do know: it'll "feel" like webdriver mainly to reduce the cognitive shift required when going from native to web-based components in hybrid testing. Either that, or the webdriver API will have to change to be more like SeMo, but I think that's considerably less likely.

Simon

--
 
 

[Graham]

just on the mobile part - I'm not saying we're the firebrands but we've had some decent success with NativeDriver.  

We have it compiling and running on iOS6.

We've updated to the latest js atoms in WebDriver

We've updated the touch events to use the UIAutomation framework by way of PublicAutomation and removed TouchSynthesis, it was causing problems on iOS 6 and xcode >4.3.

We've implemented touch events.

We have it connecting to the grid and running there too.

the nearly most up to date code is here:

https://github.com/nicegraham/appdriver

we've more to do and tidying up to do as well but it's working :)