Mozdev.org

Initial proposal by Myk Melez.

Introduction

This proposal is to build a new package of services that provides simple, effective, integrated hosting of the key services that are critical for development of and collaboration on Mozilla-related open-source projects.

Services

Those services comprise:

• revision control
• documentation
• bug tracking
• discussion

These aren't necessarily the only services we will ever provide. For example, since many Mozilla-related projects are extensions, it would be useful to provide a simple way to create the infrastructure for an extension when starting a project. But these services are the ones that we must provide in order to be useful to a significant number of projects, so they are the ones we should consider implementing first.

Also, one additional service that we must provide in order for the others to work well is an authentication and authorization system that allows project owners to specify which contributors are allowed to participate in which ways on their projects, so we will build that as well.

It's just as important to state what we shouldn't implement in this proposal. In particular, we should not provide the most comprehensive, powerful, and configurable services. We should not provide the same functionality as we provide with our current package of services. We don't have to satisfy the needs of all Mozilla-related projects. And we should not implement services that are useful to only a small minority of them.

We should aim, rather, to provide simple, integrated versions of the core services that satisfy the needs of a significant number of Mozilla-related development projects.

Our focus in determining how these services will work and the functionality we provide will be the user experience for project participants, so we mostly leave implementation decisions up to the implementors.

There are a few exceptions, however. In particular, we choose to provide revision control using the Mercurial revision control system, on which the Mozilla community is standardizing. And we bias towards other technologies standard in the Mozilla community (f.e. Bugzilla for bug tracking, perhaps Mailman/Usenet/Google Groups for discussions).

We should not bias towards technologies that Mozdev is already using, however (like CVS, Drupal, and the Hovercraft template system), since our goal is not to change our existing package of services, which would be disruptive to the group of existing project owners who are used to it.

Instead, the plan should be to build a new package of services, after which we can place the existing package into maintenance mode, allowing current projects to continue using it and making critical fixes for the foreseeable future but not enhancing it or offering it to new projects.

Simplicity

The old package had the goals of satisfying the needs of all Mozilla-related projects and exposing the full power of its services to its users. As a result, it includes services that most projects don't need, like databases, and it presents the full, complex interfaces to Mailman, Bugzilla, Drupal, etc.

The new package, on the other hand, has the goals of satisfying the needs of a significant number of Mozilla-related projects and exposing a simple, integrated interface to users. So it doesn't include services that most projects don't need (like CVS, PHP, Hovercraft, databases, and Drupal), and while it may use some of the same tools on the backend, it doesn't expose their full power and complexity to users.

Conclusion

Our community of project owners is mostly the self-selected small minority of Mozilla developers who prefer our current toolchain. Most of the rest have chosen simply to use competing services. Developers benefit just as much from usability and usefulness improvements as regular users. And not all project contributors are developers. For example, some are regular users who submit bugs, discuss issues, and document behavior. If we achieve what is in this proposal, then we have a good chance of being better than Google Code and GitHub in usability and usefulness (and certainly better than SourceForge). But even if we were only comparable to Google Code and GitHub in those respects, our non-profit status and Mozilla-centricity differentiates us from them.