Magellan/Project Overview

Project Overview

The Magellan project is an initiative to create a next-generation collaborative enterprise application development tool suite for the Linux platform. The purpose of this initiative is not to simply create another application development environment for Linux, nor is it simply about collecting, grouping, and extending existing tools. Rather, the purpose of this initiative is to understand better how enterprise application developers want to create applications, to greatly simplify the process of creating applications for the enterprise, and to better support new software development models and practices in a new type of tool that is designed with these models and practices in mind.

Over the industry's history, software development has evolved through several phases. The mechanics and the business of software development are much different today than they were even five years ago, and they require new thinking and new tools to better support the creation of applications.

• Open source has a profound impact in this arena, even if developers are not actively participating in open source projects. Solutions may now be comprised of a mix of proprietary and open components, and may be deployed on open platforms. How do developers keep pace with open source components that are constantly evolving? How do developers make use of open source components when they are not familiar with the open source process? Whether application developers work on open source, they still need to understand open methodologies in order to best leverage available infrastructure, and they need tools to help them do this easily.
• Solutions are produced collaboratively more now than ever before. Again, collaborative development is not limited simply to open source projects. One company may reach an agreement with another to leverage a proprietary library or to work together on a joint solution. A development team in one location may work with another team in another part of the building or across the globe. How do these people effectively work together on a project? They need tools that support this process.

The Magellan project aims to address these needs by simplifying the creation of applications

• for Linux
• for use in enterprise environments
• by professional (but not necessarily Linux hacker) application developers
• that leverage any mix of open and proprietary components
• in collaborative ways

About the Application Development Process

If we study the creation and use of applications by an enterprise organization, we can see that the application development process is comprised of more than what we typically think of as the application development process.

The Standard Process

The standard process is one that might be followed by a lone software engineer creating an application for personal use. The process is basically the following:

1. Identify a problem.
2. Design a software solution to the problem.
3. Implement the solution.
4. Test the solution to see if it solved the problem acceptably.
5. Repeat steps 3 and 4 until the problem is solved acceptably.
6. Use the solution.

Applying the Standard Process to Enterprises

Consider the application development process as applied to enterprise applications. Below are outlined some questions that are not addressed by the standard process:

• How does one collaborate with non-local coworkers?
• How does one maintain a source code repository without requiring intimate knowledge of the source code repository by developers?
• How does one quickly obtain implementation advice or feedback on one's task?
• How does one implement code reviews with non-local reviewers?
• How does one integrate with existing enterprise management infrastructure?
• How does one tie into the minimal subset of applications that lay users will take the time to understand and learn?
• How does one increase the likelihood that the solution will run properly on environments that are different from the development platform?
• How does one effectively receive assigned defects and work on those defects in view of the others doing the same thing?
• How does one make it easier for the target audience to obtain the software?
• How does one make it easier for lay users to install the software?
• How does one make it easier for the target audience to become apprised of newer versions of the software?
• How does one make it easier for the software to be remotely managed, configured, and maintained?
• How does one collaborate selectively - meaning, collaborate in some aspects (i.e. issue tracking) but not others (i.e. source code), or control the size of the collaboration groups?

Applying the Standard Process to Open Source

Applying the application development process to open source also brings up some new questions:

• How does one easily interact with members of an open source team that are worldwide?
• How does an open source project implement collaborative work without having to worry about the services that provide collaboration?
• How does an open source project get its product in front of potential customers?

Mixing Open Source and the Enterprise

Mixing open source and the enterprise brings new challenges to application development:

• How does one quickly find out about existing solutions or partial solutions?
• How does one properly leverage and couple proprietary and open components?
• How does one tie components together effectively?
• How does one keep up with continually changing subcomponents?
• How do enterprise application developers that are unfamiliar with open source methodologies learn to effectively use open source components and participate in open source at a pace that suits them, their job, and their employer?

Goal

The goals of the Magellan project are to deliver an application development suite for Linux that:

1. Simplifies the development of enterprise applications on Linux by non-hacker (meaning, not the traditional Linux developer) application developers
2. Promotes and simplifies collaborative application development efforts
3. Makes Linux the preferred application platform by making it easier and faster to develop applications to Linux than any other platform

Guiding Principles and Qualifications

Single Application

All of the tools in the suite should be fully usable and integrated into a single development tool application. This provides developers with one single place to do all of their development work. Developers don't have to learn how to use multiple tools in multiple applications.

Target Platform

The target platform is Linux plus one of:

• LAMP
• Java/JSP/Servlet
• J2EE
• Mono

No Price Barrier

Users should be able to utilize at least a basic version of the complete tool suite for no cost. The reason is to not make price be a barrier to someone trying application development to Linux.

Multiple Language Support

The tool suite needs to provide support for more than one or two programming languages. Required language support includes Java, C, C++, PHP, and Perl. Other strongly recommended languages include C#, Python, and Ruby.

Information Provision

Developers need to be able to search for and obtain information on SDK and API documentation, sample code, system interfaces, programming practices, and other similar information. They need to be able to do this within the tool, not just by using a web browser.

Alternative Information Sources

Users need to be able to configure the tool to search certain alternative information sources besides just novell.com sites.

Assistance with Proper Development Practice

Features within the tool should help developers comply with proper development practice and make it easy to do so, while allowing them the flexibility to deviate at their choice. This principle applies to things like open standards compliance as well as common best practices (how to properly create a listen socket, how to create a daemon application, how to create a CIM provider or a YaST module) and might be implemented via wizards or other similar tools.

Simplify Use of Open Source Components

Basic tools used in the application development process like GNU Autotools, make, RPM, valgrind, gdb, Apache, MySQL, Tomcat, and others exist but are not integrated. Many of them (like autotools) also require extensive knowledge of the tool in order to use it. The tool suite should incorporate these tools and simplify the use of these tools so developers can focus on creating solutions.

Leverages But Doesn't Require the Internet

The tool suite's information and collaboration features will be network-centric and should be. However, these components need to be designed and implemented in such a way that a live internet connection is not required to use the tool. For example, developers should be able to search online documentation when connected, but should still be able to search documentation even when not connected.

Full Development Environment Management

The tool needs to provide full control over a developer's environment - knowledge of libraries installed and where to get new ones, assistance in leveraging libraries by tying in to available information, etc.

Targeted Build Capabilities

Developers should be able to build their application targeted to specific platforms. They should be able to set this up from within their tool and obtain notification of build results.

Build Distribution

Developers should be able to set up channels for automatic distribution of builds if desired, through services such as YaST Online Update or ZENWorks Linux Management (Red Carpet).

Virtualized Environments

The tool should include capabilities to easily set up virtualized environments for testing applications on different virtual platforms. Virtualization should make it easy for developers to test applications against other operating systems that are different than the one they are using; in addition, it should help them test applications against specific environments (like LAMP).

Collaboration Tools

The tool should facilitate collaborative development by tying into select issue tracking tools (i.e. Bugzilla), source code repositories (i.e. Subversion), and notification mechanisms (i.e. mailing lists). The tool should also provide a mechanism to implement code reviews and pair programming when the participants are not local to each other. Perhaps the tool should also enlist translation services to help users collaborate who do not speak the same language.

Provided Collaboration Services

Users of the tool shall be provided with the option of using collaboration services that are provided by Novell; in other words, users don't have to set up their own CVS server to make use of CVS, since they can use a CVS server that Novell provides.

Required Tools

The set of required tools includes:

• Issue tracking
• Source code control
• Project management
• Mailing lists and online forums
• File repository
• Wiki documentation
• Targeted build services
• Package distribution services

Notifications

Developers should be able to inform the tool of events that they care about and be notified of such events. For example, a user may want to be notified in the tool when a build completes successfully, or when a change has been committed to the source code repository.

Selective Use of Services

Developers should have flexibility in using provided services. For example, with respect to issue tracking, a developer should have the following choices:

• Use Novell's public Bugzilla service
• Use their own Bugzilla service
• Use an alternative issue tracking service, and implement the tie-ins on their own
• Don't use issue tracking

In any case, the effects of this decision should be minimized. As much as possible, other features should not depend upon a specific choice.

Shared Tool Properties

Developers should be able to share not only the source of a project but the project properties itself to allow other participants to obtain the same setup and environment. Developers should also be able to share their tool properties and preferences in a non-local store, and the tool should automatically reconfigure itself appropriately when it is connected to the shared properties and preferences.

This document is a part of the Magellan project.