Before continuing on, I suggest reading Part 1, Part 2, and Part 3 of this series.
The OSS Transparency Comparison
IMHO, this is the least interesting part of my digression here but probably the most likely to be slashdotted. Nothing like doing your best to make your own predictions come true. If you want a headline statement, it is that I believe both the OSS and non-OSS worlds have some growing to do in the transparency department. I also believe that, with only a little bit of effort; it would be easy for a closed source company to become effectively more transparent than their open source counterparts of today.
Looking at OSS Transparency
Barrier to entry. Your average consumer choosing an open source alternative will have difficulty taking advantage of the transparency being offered. The primary components of open source transparency are the availability of the product source and the generally open bug database. Does the average consumer care about these things? Should they? Let’s assume they do.
The quality of the documentation and standardization of tools leveraged to develop most open source projects is a mixed bag. The most informative getting-started guide I’ve seen on an open source project is that of Open Office’s “contributing” page. If you dig under the programming page, you’ll find a “To-Do” list you could start with. They also have a decent developer page which lists “most of” the tools you’ll need to get start. Dig a little deeper and you are encouraged to join a distribution list in order to get to know the contributors and truly understand the components you wanted to contribute to. It’s also a myth that just because it’s an open project that any Joe off the street can just grab code and contribute. Of course, this is probably a good thing.
All this is great if I want to contribute to the code, but what if I just want to poke around in order to understand? I couldn’t easily find a good set of documentation that helps teach me what the source code is doing. Unfortunately, while the “cards speaking for themselves” is good for newbie poker players, it doesn’t work as well for source code. Now compare the Sun sponsored Open Office experience to your random “completed” project on Sourceforge. Downloading source is of little comfort to the average user who just might want to know the “why,” not the “how,” of a design choice that affects their every day usage.
Let’s look at bug reporting. I love how Firefox comes pre-populated with not only the link to report a bug but also the link to bug writing guidelines and the most frequently reported bugs. If I were them, I would put this stuff right under the help menu so I can’t remove these links as easily or lose them if I choose to import a huge list of favorites. There’s a link in the help menu where I can sign up to help spread Firefox, but where is the report bug link? Ok, that’s not really fair since the bug reporting page is easy enough to find. Let’s assume you’ve found it. This is where I have to give a huge advantage to most OSS software.
I find bugzilla very easy to work with, search for existing issues, and report issues of my own. The only thing I found strange was that I can search for bugs without signing in, but to view summary reports and charts for Firefox, I had to create an account. Why let me see every bug, but not overall reports? I also experienced a little bit of humor searching for “crash” on the Firefox project and getting back the text: “This list is too long for Bugzilla's little mind”. Ok, again, not fair. I really believe the open source world is ahead of any closed source corporation when it comes to bug reporting. The Product Feedback center is a start, but it just isn’t there yet, and it only lets you see other customer reported bugs, not the ones we find.
Ok, now let’s be realistic. Do these two transparency wins really make a bit of difference to the average consumer? I suggest that knowing I can report a bug and eventually get a reply from someone working on the project gives me a huge boost of confidence. Though, especially with a project like Firefox, I get more of my confidence from knowing there is a huge base of people that also could be reporting issues. The consumer in me assumes that if there is something wrong, someone will find it. That assumption could be flawed, but this is probably good enough for most people. But is a transparent bug database going to be unique to the open source world for long?
My next assumption is that most consumers couldn’t care less about the source code being available to them. And if they did care, they are quickly going to be turned off by the difficulty of understanding what is going on and lack of consistent documentation that describes the code. I’m not saying that closed source code is documented any better; just that ease of understanding is a component of transparency, and source code doesn’t score very well there. Just look at the download comparisons between the product and the code for most projects. Look at the number of users versus contributors. Source code is targeted at potential contributors not the end users.
I think some of the most transparent open source projects are those where the authors are very upfront with their plans translated into “plain English” (so to speak) for their customers. Look at RSSBandit. The main contributors regularly post about the project, design choices, and potential roadmaps on their blogs. This is certainly not unique to their project, but also not ubiquitous across the OSS landscape or something that can only occur in the open source world. The draw here, IMO, to the common user is that everything is explained in plain English for the users of RSSBandit. Kudos to Dare and crew. (I’ll admit to being biased here since I use RSSBandit every day, but it is a good example for the point I’m making.)
Looking at Microsoft Transparency
Ok, I’m lazy. I really don’t have the time to look across the closed source industry, and I happen to know the most about how Microsoft is currently trying to be transparent so I’m going to scope my comparison. I’m also cheating by looking at some initiatives that I would consider “emerging” at Microsoft. The lack of consistency makes us less transparent because we fail a completeness measure. Your view of Microsoft could also be skewed if one team adopts blogging and another does not. Customers could perceive that every team at Microsoft works the way the one team who blogs does. Every team has their own intricacies. Certainly consistency from group to group is something we could work on at Microsoft.
When it comes to source code access, I’m not sure it will ever be in the best interest of a corporation to offer full (unrestricted) access to everyone. Microsoft’s bet is around the “Shared Source” program that you can read all about here. There are licensing programs for Windows and WindowCE source code that provide an opportunity for governments, enterprises, MVPs, OEMs, and System Integrators. WIX, WTL, Flexwiki, and even most of the “original” VS powertoys (look at the right hand column) all fall under the shared source umbrella. Some of them are hosted on Sourceforge and make downloading and contributing to the code straightforward. The “How to Participate” page is probably the best way to show a comparison. I believe that corporations will gravitate over time to releasing more code along the lines of WIX, WTL, or Flexwiki, but I wouldn’t look for MS Office to emulate Open Office any time soon in the area of source access. I also don’t think source access is central to being transparent with your customers.
I applauded the RSSBandit crew and any other project where the human faces are evident as good transparency that customers can leverage. Our freedom to blog and Channel9 has done wonders in this space. Have you ever had a chance to meet the people who built the Google toolbar as you did with the MSN Toolbar Suite team? Do the people who built the Google desktop search engine have a blog you can subscribe to or a wiki they support for sharing tips, tricks, and feedback? (Yes, I know Google is closed source, but it’s the closest product comparison and I was reading this via Dare as I was writing.) How many open source projects can boast this type of transparency for average customers down to the level of meeting the people behind the scenes?
Yes, I know you could be on the developer DL for several OSS projects, and many project leaders answer questions in the forums dedicated to their projects. This is not the same for the average product consumer because of the barriers to entry and the type of information they might be looking for. I am probably biased, but there is something different starting to happen here. It doesn’t mirror the open source transparency efforts but, instead, takes transparency in a different direction.
So, looking at the customer benefits to transparency, I see us still falling behind when it comes to providing feedback opportunities across the board. Not every team has a bug database, a blog, or a wiki that customers can interact with. As I said, this stuff is emerging, but I see no reason why any corporation can’t be very competitive by providing customers with real feedback opportunities through transparency.
When it comes to Education and Preparation, there are teams at Microsoft already close to their open source counter parts. The frequency of our CTP releases are roughly at the pace of Eclipse milestone release intervals and this could still be improved. Eclipse provides more structured roadmaps for their releases than we do today, but I was hard pressed to find several Eclipse team members blogging about the features they are working on and talking about design decisions or trade-offs they were considering. The barrier to entry, however, for new customers is difficult for our blogging today. If I say “I write VB Code for Winforms,” what blogs should I subscribe to and what channel9 videos should I watch in order to prepare for Whidbey? There could be more “getting started in the community” guidance given.
Trust is a hard one to measure. There are no industry wide surveys that I’ve seen that provide a good barometer for trust. Surely there are an outspoken bunch who speaks about the issue of trust and why you should NOT trust Microsoft, but I couldn’t find something that proves this group is a majority or a minority. I spoke about this previously here after reading Giuliani’s book where he does an excellent comparison of building trust between a city government and the city dwellers to a large corporation and their customers. He talks about opening up to become more accountable to customers.
Wikipedia would have you believe that this methodology would not hold a candle to being “radically transparent”, but I would argue that being more openly accountable about the metrics a majority of customers do care about during product development (this list could vary depending on the market) would do far more to build trust than simply saying, “Here’s the source and a list of bugs … trust us.” I’m not making the case that Microsoft is as openly accountable as we could be today; I’m simply saying it’s something we haven’t tapped into very much in order to build trust.
Wrapping the Comparison
After we wrapped up filming for a Channel9 video that will never air (Yes, Virginia, filters exist on Channel9, too. Did I mention that the Easter Bunny isn’t real either?), Robert Scoble suggested to me that we were starting a “Transparency War” with our competition. If it’s transparent though, is it really a war? And if it is a war about being open with customers, then is there really a loser? Wouldn’t it help to lower the guards on both sides?
In this series, I explored the creation of a transparency guide that would help people ask good questions about the costs and values when deciding whether or not to open up an aspect of your business for customer involvement. I covered the basic components of transparency that included reflection of reality, ease of understanding, timeliness, and completeness. Part Two examined the fears associated with it, including reputation, privacy, and loss of IP, liability, and competitive advantage. Part Three looked at potential customer gains including education, feedback opportunities, education, and trust building. Finally, I embarked on a small experiment to compare the open source world to Microsoft - taking into account the first three posts.
I wanted to write this entry turned mini-series because I needed to do a better job of explaining the goals, values, and costs of this thing called “Transparency” to people internally. There really isn’t a universal understanding of these concepts today. There are some people that go around blindly saying, “We should show this to customers” (I probably fell more on this side.) and others that say “Why take that chance? Do you remember what happened when Windows bug totals ended up on Slashdot?” I hope these entries can help spawn some meaningful dialog with customers and internals alike about what it means to be transparent when you work for a large company.
I hope you enjoyed this mini-series as I pondered the transparency piece of the Visual Studio community vision. This is an open forum, and I’d love to hear any constructive feedback on how I’ve approached the subject.