Some days ago, I wrote about a QCon 2008 session where Erich Gamma spoke about transparency and how it is related to the IBM’s Open Commercial Development model (OCD). As I have been involved since last year as a beta customer in one of the projects where OCD is been applied, the Rational Jazz Project, I want to discuss with all of you some thoughts and opinions about this software development style.

First of all, and just to be clear, I’m not going to talk about which is the license model behind OCD. The words “Open” and “Commercial”, when seen together, produces some unexpected chills and thrills, and they have generated some controversial discussions out there, mainly in the open source community (maybe, as Stephen O’Grady points out, it will be more accurate to characterize this as transparent development). In the case of the Jazz Platform, there is also some confusion, because we don’t know if IBM is going to release it as an open source software and then develop commercial products based on this platform (like Eclipse), or if they, both platform and products, will remain as commercial products. I vote for the first option, but the word “commercial” in OCD suggest me the second one.

Instead, what I’m going to talk about is how transparency in a great feature in the software development process. So go ahead.

During my career, I have dealt with lots of products, from both open and non-open source software providers. One pattern that I always find in traditional proprietary software is that you never interact with the development team; there is a barrier between you, the customer, and the vendor’s developers. If you need to report a bug or to ask for an enhancement, you can only interact with a service desk. Usually, they have a support web site, where you can see your own tickets, but you can’t see any other bugs or enhancements reported by others companies. You never know when they are going to deliver a solution for your problem (except if it is a blocker), which will be the way they are going to implement your enhancement, if there are more people interested in some enhancement, … You can only check if the bug is fixed or the enhancement implemented when the vendor delivers a new version of the product, and, sometimes, results are not what you wanted. Furthermore, sometimes, you will have to deal with lots of useless questions, mainly due to misunderstandings between you, the service desk and the development team. This is what Erich Gamma calls “Swiss bank approach to software development”.

This firewall between customers and developers is really very frustrating, not only for the customers, but also for the developers. Some companies try to supply this lack of communication organizing user’s conferences (where you can meet some developers), meetings with whatever worldwide VPs, or through a customer advocate. In some cases, frustrated users set up unofficial forums to share their problems or to try to join forces so that the vendor accepts an enhancement. They try to establish some kind of user’s community, but without the vendor involvement. In my experience, and without intention to offend anyone, you will get lots of nice words, but you rarely archive a real solution.

With open-source products, there is a really different way of relationship between customers and providers. There is an open participation and customers can influence easily in the development process in several ways. And I’m not talking about having access to the source code, which is important, but also having access to the bug tracking system, the development mailing-lists, user’s forums, and, in some cases, the development plans, all of them maintained by the development team (fewer misunderstandings). This well-known transparent and collaborative model usually produces enhanced feedback, which leads to deliver better products (in terms of user’s expectations). It’s about archiving customer value, instead of vendor value.

This is the same interaction I have found while working with the Jazz Project. I have had access not only to the source code but also to the latest integration builds (so I can check how my enhancements are implemented), a wiki with technical information about the platform (if you care about the extensibility), a community forum, the development plans and a dashboard to monitor the health of the overall project. I have had also full access to the issue tracking system, where I can submit my own bugs and enhancements, but I can also see which other enhancements are requested by other customers (and to enroll them if I found someone interesting), in which version are they planned … Summarizing, full transparency in the development process. One of the consequences is that I’ve felt, and this is personal and subjective opinion, more involved in the development process, more biased towards submitting enhancements and more confident about future problems that could appear. This feeling is nothing new if you have previously worked with open source projects, but it is something strange coming from an proprietary product.

However, there is a huge difference between open source and OCD models. While in open source software you can contribute to the code base by fixing a bug or improving some features, in OCD it is not clear which will be the contributor’s role. It will depend on the license model selected, which, in turn, it will establish if there will be a vibrant community and ecosystem outside IBM or if there will be a vibrant IBM’s customer community. Anyway, if the final decision is to keep the software as a commercial product, the transparency applied in this model it will represent a great improvement in the proprietary software development process, for both customers and vendors.

But after using this software development style for some time, I believe that this model it is not useful only to software vendors, but it also could be applied to any IT department, especially in big enterprises, in order to improve their software development process. I also believe this is one of the objectives pursued by Rational Team Concert, the first product based on the Jazz Platform (I will talk about this product in future posts). But this is something that I need to try by myself in the company where I work. As most of my readers already knows, I am in charge of the application developments tools in one major Spanish savings bank. Looking through the development process we use, I am sure that if I ask the users of the tools we develop (our internal customers) how much transparent are we, they are going to complain me. Although we meet periodically, it is hard to achieve transparency only with meetings, we need to adopt different and innovative approaches, the ones I have told you in this post.

And finally, although this is what I honestly think about transparency and OCD, I want to hear other opinions. Do you think this is a good software development model for proprietary software? Do you think this model could be applied inside enterprise firewalls?