SwingLabs is an _open-source_ project: that means you have complete access to all the code, all the discussions and you, dear mortal, help decide the future of the SwingLabs toolkits.
All SwingLabs code is released under one of two approved open source licenses: the GNU Lesser General Public License or the Sun Public License, . All contributors (those who don't already work for Sun--which is many of us) sign a copy of the Sun Contributor Agreement, allowing Sun to re-use the code in the standard JDK if they wish. But the SCA doesn't restrict how you use the toolkits--they are licensed under standard FOSS licenses, so all users retain the rights to run the software, study it, improve it, and share both the originals and their improvements with others.
The SwingLabs home page has information on contributing to SwingLabs. The SwingLabs community has a set of governance guidelines that is used as the basis of how co-operative work is done for SwingLabs, and its sub projects. This Wiki page should be seen as an addendum, or additional information on the process. If you have any questions regarding the legal or practical issues around participating in SwingLabs projects, please contact the SwingLabs project owner (currently Richard Bair), using the email address on the SwingLabs home page.
all of the code you want to contribute is licensed under the license for the target sub-project (LGPL or SPL) and all of the contributors to that code have agreed to that licensing
The Process
The process works like this: after signing the SCA and joining the particular SwingLabs project, you ask for (and will receive) CVS access to the SwingLabsJdnc Incubator?. Check your code into your own branch of the incubator, with documentation and a runnable demo. Then post a message to the mailing list and let people know it's available. In due course, you'll get feedback--sometimes surprisingly detailed feedback. Once you've absorbed (and responded to) the discussion, you can ask that your component be accepted into one of the SwingLabs projects.
Running the Gauntlet
The committers on that project will then discuss this and vote on it. If the code is accepted, it will be merged into the main CVS branch for the project. When this happens depends on a number of factors--there are features freezes before major releases for example, and sometimes developers are pretty busy. But if it's voted on and accepted, it will make it in.
Be ready for this discussion: some of the people who review your code will read it very very carefully. And the comments you receive may be pointed. On the mailing lists we are unfailingly polite and brutally honest. You may hear
this looks like duplication of effort, why?
this is a completely non-standard design
this challenges fundamental ways in which Swing or Java works
You have to be ready to run the gauntlet, explain your position, defend your ground and--most importantly--be willing to listen to criticism, feedback and advice, and make changes to suit. Keep your cool, even when you feel your ideas are being strongly criticized. The software engineers who contribute to these projects have high standards, and will hold you to them--but they always listen to good, well-written discussion and argument, and you can change their minds if your ideas are good. The upside is that what makes it through the door will have been put through its paces--and the end users of your toolkit will be much happier because of it.
Reasonable Expectations
What we expect:
all code meets high standards of design and follows standard coding conventions
the design follows standard practices in place in the Java JDK and Java Swing
all JavaDocs are available
external documentation is available for what doesn't fit in the JavaDocs (e.g. basic tutorials, demos)
JUnit tests are in place and runnable on demand for automated testing
you should expect to be the contact person for any problems that arise with the code you wrote, and you should provide documentation for it and help in answering questions as to its use.
The Vote, and What it Means
For various reasons, some code that is great quality will not be accepted--or may be deferred. Don't be disappointed! If your package is stable, we will help you in making a release available through the incubator, which will meet the standard requirements for a SwingLabs release, but will be optional for download.
Get Started
So what are you waiting for? Send in a copy of the SCA and start hacking! You may have an new idea, fresh insight, something you just want to play around with--we love it! Post whatever you have as soon as you have it working, include easy-to-run demos and promote it ruthlessly :). SwingLabs is not just about creating high-quality toolkits but about exploring uncharted territory and imagining completely new futures for Java desktop development. You can make it happen--just go for it!