Movable Type.org

You don't have to be a hacker to help make Movable Type better!

The Movable Type community seeks to include anyone, regardless of background and skill set, in the process of making Movable Type better. Anybody can help, and here's how:

• Help other users - spending the time to answer just one question you know the answer to in the forums, or helping a friend upgrade to the latest version of the software is the kind of contribution that is beyond measure.
• Create a theme - Got HTML, CSS or design chops? Then by all means create a new design for a Movable Type powered blog and share it with others.
• Report a bug - Notice something wonky? Then send us feedback and someone will take a look at it. Go the extra mile and help document ways to reproduce the issue to make it easier for others to fix.
• Fix a bug - If you have the means, we of course welcome the help from others in fixing issues in the product. This page details ways to submit your code fixes.
• Build a plugin - One of the best ways to prototype an idea, or deploy new features to the platform is to build an add-on to the platform in the form of a plugin.

Contribution Process

The process for contributing code is evolving, based on feedback from the community, the core development team and Six Apart.

Contributions in the form of bug fixes will often come through our bug tracking system. For small, simple, or relatively "obvious" fixes, this medium is perfect and users should feel free to do this.

For larger more substantial fixes and/or feature enhancements we ask that the mtos-dev mailing list be used so that a larger group can review and provide feedback on the proposed change.

Using the Mailing List

To submit a contribution for review by the community we ask that you first subscribe to the mtos-dev@sixapart.com mailing list. Then send an email to the mailing list containing the following information:

• a brief summary of the change
• the rationale for the change - why is it needed and how will it help others.
• a technical overview of the change - to be courteous and to save people time in sifting through code, summarize the contribution from a technical standpoint.
• a diff of all the affected files.

The mailing list will serve as a permanent record of the proposed change. Then others from the community will be free to review the contribution and provide feedback. Together with the community, changes will be iterated upon until consensus is achieved. Finally, the contributor must agree to the terms of contribution, and then the contribution will be committed to the source code repository by the core development team.

Got a Patch? File a Bug!

If you are awesome and made a code fix or patch that addresses an issue in the application, we wan to see it so we can review it and incorporate it into Movable Type. To submit your patch, you'll need to have an account in our Fogbugz bug tracker. Then, you can just file a bug and include your patch as an attachment on the bug.

Terms of Contribution

Six Apart, in accordance with many other notable open source projects, requires that contributors sign (or an electronic equivalent) a Contribution Agreement. In this agreement the contributor assigns the copyright of their contribution to Six Apart.

In so agreeing, the developer gets the following benefits:

• Six Apart takes full responsibility for the maintenance of the contribution
• Six Apart takes full responsibility for the testing and quality assurance of the contribution
• Credit will be maintained and attributed to the developer in the source code

Why does Six Apart make this requirement?

The revenue generated by the Movable Type commercial product supports and subsidizes the continued development as Movable Type as a whole. To serve the thousands upon thousands of Movable Type Commercial customers, Six Apart requires the flexibility of being able to license Movable Type in a variety of ways. In other words, Six Apart needs to ability to dual license Movable Type.

To modify or change the licensing terms of software requires permission from all the copyright holders. Therefore, to make this process of dual licensing easiest on all parties involved, Six Apart asks that contributors assign their copyright upfront.

Will code I contribute ever be turned into closed source software?

All contributed source code made under the terms of GPL will always and forever be open source. That is the benefit and guarantee of the Gnu Public License and why Six Apart chose it for MTOS.

My copyright is important to me, is there anything I can do to retain it?

We recognize that the copyright assignment requirement may be controversial to some, which is why we provide a number of different ways people can contribute to the project without relinquishing the copyright to their code. Movable Type's plugin API provides a vast number of interfaces into the product and can be used by developers to build a great many features and applications on top of the platform.

There is a great deal of precedent even for popular and valued plugins to be bundled with Movable Type in such a way that allows the original author to retain their copyright.

Do I need to do a lot of paperwork just for contributing a simple bug fix?

Legally ad technically, copyright assignment is only required for contributions which are unique and demonstrate clear innovation. As such, if it a bug fix is "obvious" then no, a contribution agreement is not required. Project committers (people who have rights to commit changes to the code repository) have been trained to identify "obvious" fixes and what to do if there is ever any ambiguity.

How are contributions evaluated and on what basis are they accepted?

All incoming code contributions are evaluated by the community and by those with commit rights to the repository. Incoming contributions are reviewed to ensure security and the integrity of the overall product.

Reviewers will also assess the contribution's adherence to the overall objective and mission of the overall project. To that end, reviewers first determine if a contribution is better implemented as a plugin in an effort not only to keep the core platform as lean as possible, but also to give end users as much choice as possible regarding how they wish to extend the core platform with additional functionality. If the community feels that the contribution is best implemented as a plugin then they will encourage the contributor to package their contribution as such. If it is determined that changes are needed to the core to facilitate such a plugin then the reviewers will encourage the contributor to resubmit a smaller patch that will enable such a plugin to be built.