What, why, when and how – these are the questions that shape the communication between the product developers and their users. Different teams choose different levels of opacity regarding these four questions, and making the answers more opaque over the time leads to a building frustration among the community members. This has been one of the major reasons behind my post on the current state of core Swing, and allow me to further explore this area.

Open-sourcing Java during the JavaOne 2006 and the announcement of OpenJDK project was hailed by Sun as the new era for Java, where everybody can lend their hand in shaping the future of the Java platform. Specifically in the client area, the summer of 2006 has supplied Swing developers with such gems as Chris Campbell’s entry on soft clipping, Chet Haase talking about Java on Vista, official birth of JSR 295 and JSR 296, as well as lively discussions on the SwingX painters and layers. Those have been exciting times for me personally, as they showed a renewed and well backed interest in the Java client side development.

Unfortunately, the last eighteen months have been quite disappointing. The level of openness (or transparency, if you will) set in the summer of 2006 was not a genuine and lasting commitment to the community, which has been effectively shut not only from participating in the decision making process, but in following it as well. And this brings me back to the four questions – what, why, when and how.

The how is perhaps the easiest one, and Java has always been shipped with the matching source archives. This has allowed the users to understand not only how the specific piece works, but also how to work around the specific bugs in order to achieve the required functionality. Even if the internal technical design documents (if any are present) are not available to the community, the full source code is an excellent reference guide to a deeper understanding of the platform and becoming a better Java developer in the process.

The answer to when allows bigger projects to estimate timelines for the different technologies, both existing and emerging. In this area, Java has not been a great success over the last three years. The new 18-month release cycle for major versions (announced at JavaOne 2005) which would have Java 6 ship in summer 2006 and Java 7 to ship in early 2008 has failed, without any explanation or apology. While the main reason for “slipping” Java 7 is the great work that has gone into Java 6 update 10, we still don’t even have the umbrella JSR for Java 7.

The answer to what allows estimating the functionality for the different technologies in coming to decide which one to use. Will we have a cross-platform Swing web browser component in Java 7? Will we have a public Swing API for translucent and shaped windows in Java 7? Will we have a public Swing API for playing, manipulating and producing video streams in Java 7? Will we have binding layer for Swing applications in Java 7? Will we see modern Swing components such as pivot table or date picker in Java 7? Withholding answers to these questions has been a normal practice for the past eighteen months, and this opacity has resulted in quite a few disappointed advocates of the toolkit.

The answer to why defines the level of trust between you and your community. You can be extremely opaque, not only making your decisions behind closed doors, but also presenting them as the only right way. You can be somewhat translucent and write about the reasons behind the decisions, even when the decisions themselves are made without any input from the community. Or, you can be extremely transparent and have the community participate equally in shaping and moving the platform forward.

Different projects will differ in their level of opacity. One-man open source projects are different from commercial companies that are frequently judged by revenue stream and monetization. You have the extremely opaque Apple and somewhat translucent Microsoft. On the other hand, you have an incredibly open Mozilla that already has 61 posts on its aggregator since the beginning of this week. And in between you have projects such as Qt Labs that are engaging in early feeback cycle about emerging functionality in their toolkit.

The last two examples (Mozilla and Qt Labs) show a continuous level of commitment to the two-way communication with their users. Is this coming from the developers? Is this coming from the management? Does it matter at all to your developer users?

If you’re starting a blog about the product and then abandon it after a few weeks, why start it in the first place? If your project has the word “open” in it and then you want to suppress the discussion about the planned features, why bother pretending? Do you really want to hold all your cards close to your chest if you’re trying to compete against a formidable opponent, especially when many of your pre-announced features are already in his well established offerings? Can you afford keeping the potential developers out of the loop instead of using the power of dev-to-dev blogs to build up the excitement? Is it beneficial to your project to hide behind the “open source you can help us instead of whining” mantra, when my chances as a potential outside contributor to add significant new functionality (as opposed to fixing a bug) are almost non existant?

And lastly, can you justify being “heads down” in development / testing to create a void to be filled with rumors, conjectures, interpretations and wild guesses?