[Tools-dev] Proposal for fork of Selenium

Mikeal Rogers mikeal at osafoundation.org
Thu Nov 9 17:28:42 PST 2006


This is a proposal for what amounts to another project at OSAF  
managed by people in the tools group.

It shouldn't come as a shock to anyone considering that we've been  
having to maintain a selenium branch of most of their projects in the  
tools repository for some time. It's at this point that we've decided  
we must fork the code.

The major reasons are all community based. Our patches can't make it  
in, and our complaints about architecture and ease of use have fallen  
on deaf ears and we get the impression that Selenium is a particular  
organizations project that happens to be open source, rather than a  
through and through open source project. Adam and myself have been  
sitting in #selenium on freenode for months answering people's  
questions as they come in -- we have yet to talk to a selenium  
committer a single time.

Beyond the fixes to the selenium core javascript api and rewrite of  
the python remote control library we have a huge problem with the  
sustainability, ease of test writing, debugging and general approach  
of the selenium remote control server which we intend to fix with a  
complete rewrite with a RPC based approach. In addition we feel that  
we can make a strong impact in this space by running a much more  
transparent and open project, along with much better tools and  
acceptance of outside committers.

We tried to work with those at Thoughtworks and openqa.org previous  
to this choice and have decided that the only sustainable solution is  
to fork Selenium and create a new project that takes the existing  
code and tools in a better direction.

Here is our list of upcoming work items:

- Figure out a name for the project
- Work with Ted to go over all the legal requirements
- Setup a trac install and a new subversion repository
- Work on a vision statement and roadmap for the project
- Work out a clear architecture plan
- Once we reach our first intermediate release we should probably  
break the project's mailing off of the tools list and on to a  
separate list.
- Write lots of code
- Anything I've missed


More information about the Tools-dev mailing list