[MTOS-dev] On using third party libraries, and getting code accepted

[Byrne Reese]

I started this email a while ago in response to questions regarding how we
go about doing a better job of replacing core MT-only libraries with more
broadly adopted 3rd party libraries.

I send the email now in an interest to answer people's common questions
about making contributions to MTOS and to work with the community on
refining this process to make us all more productive and to advance MTOS as
quickly as possible.

Let's first talk about the design goals for MT's core vis-à-vis 3rd party
libraries, and then talk about priorities, schedules and roadmaps, and
finally talk about how we can all work together to help us achieve those
goals.

DESIGN GOALS

I don't think you will find anyone in this group/community that will
disagree with the desire to embrace as many 3rd party applications as
possible, or with the desire to replace existing functionality with more
widely adopted 3rd party equivalents.

Tim's makes one very compelling point about the benefit of doing so:
documentation. By embracing 3rd party code, we get more people involved in
supporting MT - even if it is indirectly. We also get use of all of their
documentation as well, which addresses another of MT's current weaknesses in
the developer community.

Those are some pretty big wins, and that is why few will disagree with the
intent.

PRIORITIES, SCHEDULES and ROADMAPS

Six Apart's #1 priority for Movable Type right now is to improve
performance. The second priority is to make the application itself simpler
and easier to use - especially for designers, who right now struggle to
comprehend our default templates. Those are the two issues Six Apart has
committed to addressing in the 4.2 timeframe.

That does not preclude the community from contributing features and code in
addition. For example, Arvind will be contributing Simply Threaded, and
Hirotaka contributed the memory leak patch, and hopefully will begin work on
other projects he has expressed interest in - like modularizing MT::App.

Feature vs. Schedule Driven

We have maintained a pretty aggressive schedule since MT 4.0 was initially
released, and the commitment of ours to release MT on a quarterly basis is
an important one, and one we will keep.

Our Schedule

Ideally we will be able release 4.2 as early in this quarter as possible.
The desire is to have a beta starting at the end of this month and
proceeding into April for a release then. That does not give us much time
and very little luxury for six apart to venture beyond its own goals I spoke
about earlier (performance and ease of use by designers).

Relating this back to the use of 3rd party libraries...

To the extent that using a third party library will help us achieve one of
core goals for this release, Six Apart is more than willing to devote its
own resources to incorporating that library.

But given the time constraints and priorities, it is unlikely that we (6a)
will have time to devote to the extensive work that would be necessary to
rip out MT::App::CMS with CGI::Application (for example). Doing something
that low level takes a serious commitment of resources in both evaluating
the fix, applying the fix, and then testing the fix. And our focusing on it
would put our other goals at risk.

However there is no requirement that states what Six Apart and the community
works on must be the same. While I think it is important for us all to be on
the same page and for us to be working towards the same goals, it is also
important to the extent that the community feels free to take on certain
projects on its own, it should feel free to do so.

Which begs the question, if Six Apart is off pursuing one set of objectives
for the product, how is the community to get its code and ideas merged into
the core?

HOW TO PROCEED

Small things are always easy to get committed. We actually incorporate small
patches and bug fixes all the time. What gets harder are the larger
projects.

Let's take the CGI::Application project for example, which is something I
have heard mentioned several times.

So how should the community, IMHO, go about tackling this project. First the
idea needs to have some buy-in, which I think in this case, it does. There
must also be some good discussions on how the code/feature might work
conceptually and in depth. In my mind, the most important part of this list,
which so far has proven to be true, is the analysis this group provides on
the ideas presented here.

But in regards to moving an idea, even a thoroughly debated idea into the
core product, I think the single best way is to illustrate how it would work
in a very basic and limited implementation of the idea. Using
CGI::Application as an example,  perhaps one could create a prototypical
implementation of single screen in MT that would utilize this framework -
the dashboard and the login screen for example. How to do that?

Check out the code from a stable branch - then create your implementation. A
quick 'svn diff' will allow you to submit diffs to the community to evaluate
themselves.

This simple implementation will also help us to gauge how much additional
work would be required to see the implementation through to the end, and
help identify risks from a QA standpoint.

The challenge of course is to limit how much work is invested as there is no
guarantee that the community will agree in the end on investing the time
required to finish the project will be a good idea.

But again - the proof is always in the code and finding the right balance
between the work necessary to prove a design, and talking an idea into the
ground.

Byrne Reese
Product Manager, MT