From the day we conceived TFS back in 2003, we knew that we wanted it to be an open platform upon which anyone could build their favorite development experiences.  We started by building an architecture based on standard technologies – SQL Server for the datastore, Reporting Services and Analysis Services for analytics, web services for the protocols and a .NET object model for easy programmability on the client.  I remember starting in the very early days with the rule that there’s nothing our clients can do that our customers can’t also build clients to do – no secret APIs, no insurmountable protocols, etc. I guess I’ve just always felt that’s the “right” way to build software – layer the software with clear contracts at each level and expose those contracts for anyone who wants to use them.  Visual Studio itself has been a good lesson for me – both positive and negative, in this respect.  Since the mid-90’s VS has had a great extensibility architecture.  The shell provides a bunch of pluggable services.  Packages can consume existing services, proffer new ones and negotiate levels of service.  It’s pretty nicely done (though a bit more complicated than I wish).  In that respect, it’s a great example of how to build an open platform for an ecosystem to develop. At the same time, I remember when I first joined the Visual Studio team back about 1998/99.  The Visual Studio architecture was available then but we only made it available to VSIP partners (a partnering program that was, at the time, only really practical for commercial partners).  I remember asking why we didn’t make the VS platform available to everyone.  The answer was “if we made it available to everyone, it would be so expensive to support, we couldn’t afford it”.  I hear various forms of this kind of fear from people from time to time and on varying topics.  It’s is form of anxiety that if I lose control of something and I don’t know exactly what to expect, I might not be able to handle what happens.  It’s rooted in wanting to make sure everyone has a good experience and their expectations are met.  However, I’m reminded of that line from Jurassic Park – “Life finds a way”.  The software community is similar.  Providing access is almost never a harmful thing.  You may not have all the docs, samples, support, etc you might like but the community will find a way.  They will dig and pry and ask and share and will make something great out of what you provide.  Obviously, we have subsequently opened up VS for all to see and extend but, in my personal opinion, failing to do that circa 1998 is one of the biggest blunders we (DevDiv) have ever made.  We hampered an ecosystem that was ready to blossom because we were afraid of not being able to handle it. Well, water under the bridge and I think we learned a good lesson there.  We certainly set out with TFS to make sure we took the right path.  Certainly there are things we could do better – I wish we had better API docs, more samples, etc.  I wish the WIT web services were more approachable.  I wish we’d had the time to open up our UI extensibility more.  But there’s a ton there and we’re making progress on opening up more everyday. Another lesson from my past comes from the first company I ever worked at – DaVinci Systems.  In the late 80’s and early 90’s, DaVinci was one of the premier email vendors.  We had the first email client for Windows and were widely recognized as the most easy to approach email system around.  We were awarded PC Magazine Editor’s choice 3 times.  Ultimately, the company failed, despite a great product and a pretty large user base (at one point).  There were many reasons; however, in my opinion, one of the significant ones was that we did not focus heavily enough on interoperability.  Our competitors ensured they could connect to everything – SMTP, Profs, MHS, Mac, Unix, … and we stayed mostly focused on building the best and most friendly PC based mail client.  Ultimately the lack of interoperability contributed to our demise as it became more and more important to customers. Just over a year ago, we took a big step and broadened the TFS ecosystem to include developers from other platforms – Java, Linux, Mac, Unix.  It was a recognition that for TFS to really be the lifecycle tools platform for the next decade, we need to make sure it’s available to everyone everywhere – hence the name Team Explorer Everywhere 🙂  Just over a year ago, we introduced the TFS Integration Platform – another key technology to integrating TFS into the ALM ecosystem.  And we have followed up by building on top of the integration platform – for instance the ClearCase/ClearQuest integration tools.  And much more is in the pipe.  We continue down the path to making TFS the most widely available, the most extensible, the most interoperable lifecycle platform on the planet. Over the next few months, I’m going to write a blog series that spotlights the great things that can be done and are being done with our platform and the efforts we are making to open it up even further.  The ecosystem is rich and thriving and growing constantly.  Developers are passionate about their tools and we’re thrilled to provide an avenue to help people bring those passions to life.

Brian