So you want to be a Windows Installer XML developer?

People have started expressing interest in joining the Windows Installer XML toolset development community so I figured I should get some administrative details out of the way.  If you are interested in contributing code to the Windows Installer XML toolset, it is very important to read through all four of these topics.

1)  The Windows Installer XML toolset copyright is held by Microsoft.

I want to be very up front about the copyright of the Windows Installer XML toolset and how it affects us as developers.  Microsoft is the sponsor of the Windows Installer XML project.  Before a contribution can be accepted into the WiX project, the lawyers have asked that we assign our rights to those contributions to Microsoft.  By having developers sign a copyright assignment agreement, Microsoft can maintain single legal control of the project.  That single legal control enables Microsoft to best defend the project in the future if there was ever any sort of legal challenge.

Before jumping to any conspiracy theories, please note that this copyright assignment is exactly the same process the Free Software Foundation has you go through if you work on a project they sponsor.  Also, in Clause 5 of the Windows Installer XML assignment agreement your rights to your contribution are explicitly granted back to you.  If you would like a copy of the assignment agreement, please contact

2)  The Windows Installer XML project is a benevolent dictatorship.

In order to ensure consistency in the schema and maintain the quality of the tools, the Windows Installer XML project’s CVS tree is locked down.  In other words, commits to the code-base by the general populace are prevented.  If you attempt commit changes, CVS will inform you that you have "Insufficient Karma to complete the task."

To have your contribution submitted to the project, please submit an assignment agreement as described above (you only need to do so once) then send your code diff to  The developers there will review the changes and someone will apply them to CVS as quickly as possible.

3)  The Windows Installer XML community is a meritocracy.

Those individuals in the community who demonstrate an understanding of the code base by actively participating on the Windows Installer XML mailing lists and consistently submitting high quality diffs will be given a “Karma boost”.  With enough Karma you will earn the ability to commit changes directly to the Windows Installer XML project’s CVS tree.

Commit privileges should not be taken lightly.  It is very important that the WiX toolset maintain a high quality bar because many people depend on the tools working properly.  Very few developers earn these privileges.  In fact, in over four years of development, only five developers have earned commit privileges to the internal Windows Installer XML project.

4)  The Windows Installer XML developers are all volunteers.

Everyone (to the best of my knowledge) that works on the Windows Installer XML toolset does so in his or her free time.  Please keep that fact in mind when asking for help, submitting code diffs, or interacting with any members of the project.  We all want to help to make the Windows Installer XML toolset as solid a tool as possible, but sometimes “real jobs” and “significant others” have to take a higher precedence.

If worse comes to worse, you have access to the source code.  Try reading for a while. ๐Ÿ™‚

Comments (16)

  1. shayne says:

    No seriously man. lol.

  2. ian says:

    good post but all pretty standard for open source. Maybe this is the first open source project you’ve worked on or at least it looks that way from the wording of item 2). In my experience with a number of different oss projects almost no one expects commit access right away. What usually happens is that once a given developer is consistently submitting clean and useful patches that require a minimum of review and demonstrates deep knowledge of the project in mailing list discussions its simply easier for the project leaders to give them commit access than to continue reviewing every patch.

    I would encourage the sending of patches to a developer mailing list so that they can get peer reviewed by multiple people. Of course you still have the final say – its your project – but posting to a public forum gives you one of the key benefits of the oss model. Quite often I’ve learnt new things or taken different design decisions based on input from unexpected sources. You’ll find that there are people using the code in ways that you’d never thought about.

    ditto item 4 – by definition most developers on oss projects are volunteers. Maybe this is becoming less true for some bigger commercially sponsered projects but in the main it still holds.

  3. ian,

    Thanks for confirming (at least tentatively) that the WiX project isnโ€™t significantly different from any other OSS project. With this blog entry, I was trying to get all of the administrivia out of the way so that anyone who is new to the Open Source development process or questioned if a Microsoft sponsored OSS project was the same as other OSS projects could read through it right here and (hopefully) understand how this project works.

    Also, I very much like your suggestion about sending diffs to the mailing list. I will update this blog entry with that suggestion.

  4. I second the motion of sending code diffs to a developer mailing list for peer review. (I wouldn’t recommend them for the general users mailing list, though.)

  5. Reid Gustin says:

    ian: As for developers using the code in ways that we’d never thought about, there’s no question about it. It’s been really interesting to watch the bugs that come in to the SoruceForge project, as so many of them relate to Dark. The Dark decompilation tool is new, and only used lightly internally. The code is getting put through its paces in so many ways that we haven’t hit yet at Microsoft, and I think what’s going to happen is that the quality bar on Dark in particular will shoot up in the next couple of weeks. Very cool stuff.

  6. Peter Torr says:

    This is not a cheer-ocracy. Rob is the cheer-tator. He will make the cheer-isions around here, and he will deal with the cheer-onsequences ๐Ÿ™‚

    Any cheer-estions? ๐Ÿ™‚

  7. AT says:

    ;o) Hmm .. I was thinking it was copyrighted to IBM.

    CPL.TXT file in reffer to IBM as "Agreement Steward" and entire agreement if governed by the laws of NY instead of WA ;o)

    Taking IBM as "Agreement Steward" make it impossible for Microsoft to change license to own code.

    Probably copy/paste error ? Or Microsoft was lazy to write and support own Open Source compatable license agreement ?

  8. I have updated this blog entry to fix the mailto: links (they were all corrupt) and note that diffs should sent to the newly created as per the suggestions above. Thanks.

  9. AT,

    IBM is the steward of the CPL license but not the Windows Installer XML toolset code that is licensed under the CPL. If you look at the top of any of the source files, you will see that Microsoft holds the copyright on all of the source code posted to the WiX SourceForge project.

    Also, what value is there in anyone (not just Microsoft) creating another license (OSS or not) when a license that seems pretty appropriate already exists? It seems very likely that people would criticize your efforts if you created a license that duplicated an existing license. Ultimately, the CPL was a good fit for the Windows Installer XML toolset so that is what we chose.

  10. Catalin says:

    I want to know…what is the advantage of this toolkit versus the classic Orca ? I still don’t understand what advantages does this solution hold over creating the MSI with Orca.

  11. Orion Edwards says:

    Advantage over orca? Scriptability. That’s the whole point of it. The only way to put things into tables in orca is by point and click. You can’t for example put it in an automated build process. You can with wix.

    Also many people find it more convenient to edit a file (especially with visual studio’s xsd-based autocomplete, which is great) rather than to click around a million dialog boxes. (Hence I’d prefer wix over installshield any day) Pretty much just use orca as a debugging tool.

  12. Catalin says:

    Well, I put things in my databases using the Windows Installer object which I instantiate in a script. The only advantage I see for wix are:

    1) The text source files are kept better with source control systems than the msi binaries ?

    2) Better control over intellectual property ?

    3) The resemblance with the traditional coding stages ( write text source code, compile, and link to a binary ).

    4) Maybe the next MSI file format will be XML-based ? ๐Ÿ™‚

  13. Imagine a blog entry where I take a Microsoft employee’s questions and turn them into a mock interview in a public forum (i.e. my blog).

  14. How to use the wix.targets file in recent WIX distributions to compile packages using MSBuild.

Skip to main content