MSBuild Team Posts Status Publicly


Kudos for Alex Kipman and the MSBuild team for starting to publish the project status publicly.


From the comments on their first post:



  • I love this kind of transparency. Keep it up! I wish every PM did this. I just couldn't help thinking if you're gonna get sacked tomorrow for revealing too much inside information. 😉

  • I think it's great that you find the time to let us know what's happening internally and how things are progressing. It helps us doing strategy design know how to position what's to come so please keep it up (dozens, if not hundreds of MS Softies have been doing this so this is a good thing).

And Via “The Daily Grind



  • Alex Kipman posts a status report on the progress of the MSBuild component of the next version of Visual Studio. Imagine a world in which every Microsoft team posted this info publicly...

Which prompted more than one internal softie to tell me:



  • Actually I think this should be an official recommendation – every public team in MS should post status info regularly like this.

Good Times!

Comments (9)
  1. Adam says:

    Just when is the blogging unreality field going to wear off? Status of internal projects may represent competitive information, may have legal consequences to contracts, expose security bugs before the fixes are deployed, and may represent excessive transparency.

    I work on something inside MSFT that would sink existing product lines. Should i post our build status information? <absolutely not>

    Next they’ll want us to start publishing checkin mail?

  2. josh ledgard says:

    Adam: I agree that there will always be a need for a "Black Box" of information that customers (or at least the general public) do not need, nor should they, have access to. I think that’s why the quote suggests this only for "public" products. Maybe MVPs should have a smaller black box than the general public.

    So maybe for your team only a small set of MVPs or partner customers have access to this information. Then, when your product is publicly announced you have a set of customers who have been with you from the beginning that can help you evangelize and form the public community. Then you could post the information publicly.

  3. josh ledgard says:

    Adam: Feel free to contact me internally and we can discuss this further if you like. 🙂

  4. Josh and Adam,

    I agree with both of you. I think transpacency is a very good thing for both Microsoft and their customers (be them application developers, IT staff, or end users). However, every person that is bringing such transparency SHOULD verify that he or she is allowed to expose the information publicly or not, within the legal, contractual, or competitive guidelines that the team he or she works in has.

    Transparency is good and brings a lot of benefits, but you have to be very responsable about what you’re making public and what not.

    However, Microsoft is made up of intelligent people (at least all the people I know from within Microsoft are so), and intelligent people can be very responsable, so I don’t fear about things like information leaks through blogs or so… Am I right?

  5. josh ledgard says:

    Sorin: Agreed. I wouldn’t advocate people on teams doing this without first checking if they should or if they might be giving away information they shouldn’t. (Hence why you see Alex carefull not to give away too many details about partners and company names. )

  6. Adam says:

    [i notice i’ve included someone else’s proposal to include checkin mail in this comment]

    Where this logic breaks down is as follows:

    * I’m on a project > 2000 people. Because of the size and complexity of our project, most individuals have a really limited view as to what information is public and what information is not.

    * Distributing responsibility to this many people pretty much ensures that someone will screw up. The percentages are against us.

    * Taking things that are considered internal communication and making them public interferes with there internal value. I don’t want people gathering up checkins so they can checkin a FEATURE that can be publically acknowledged rather than fixing bugs.

    * I’m concerned about making everything about the external exposure. We need to fix bugs, we shouldn’t be thinking about how pretty the checkin mail, whether it has enough context for the external user, etc. I’m also concerned that this again prioritizes features over fixing bugs.

    Distributed responsibility is not realistic. Individual developers just can’t be that well informed on a project this size, internal communication shouldn’t be burned with the assumption that it will become external communication, and this level of transparency assumes a competitive/regulatory/legal landscape that my group doesn’t operate in.

  7. jledgard says:

    Alex has a responce to your comments posted on his blog. I’m not sure i would add anything to it.

Comments are closed.

Skip to main content