~launchpad-pqm/launchpad/devel

=============================
Launchpad: Strategy and scope
=============================

*We want to make Ubuntu the world’s best operating system. To do this, we need
to give Canonical an edge in productivity over and above other Linux vendors
and, just as importantly, help make the development of open source software
faster, more efficient and more innovative than its proprietary rivals.*

Launchpad does this by helping software developers share their work and
plans, not just within a project but also **between** projects.


Introduction
============

This document tries to answer two big questions:

1. *why* are we making Launchpad?
1. *what* is Launchpad supposed to be?

When you are finished reading this document, you should know what problems we
want to solve, what we hope to gain from solving these problems, how we decide
whether something is in scope or not and how we know if Launchpad is doing
well.

This is not our strategy for the year or our scope of Launchpad development
for the next six months.  Rather, it is our answer to the fundamental
questions: what is Launchpad and why is Canonical investing in it?.


Audience
--------

This document is for everyone who cares about improving Launchpad. Primarily,
we’ve written it for Launchpad’s stakeholders within Canonical and for the
developers of Launchpad, whether they are Canonical employees or not.


Strategy -- Why are we doing this?
==================================

The world we live in
--------------------

Open source software is bigger than you think.  It is much more than simply
writing the code.  Code has to be packaged, integrated and delivered to users
who can then give feedback and file bugs.  Distributions made up of tens of
thousands of different software packages need to be released to meet a
deadline.  Translations must be made into hundreds of different languages and
accumulated from a variety of sources.  Everywhere bugs need to be tracked,
fixed and checked.  Plans must be made and kept.  Distributions have to be
made to work on a wide variety of hardware platforms with varying degrees of
openness.

Those who make open source software and wish to profit commercially also face
unique challenges.  Contributors are scattered across the world, making
coordination, communication and alignment just that little bit more difficult.
Many contributors are volunteers, and so decisions must often be made by
consensus, deadlines enforced without the leverage of an employment contract
and quality maintained without formal training.  Users of open source software
use a widely heterogeneous stack of software and hardware, thus increasing the
burden of compatibility work.  All of these things make open source software
development more difficult, thus increasing the need for tools to aid
collaboration.

The Ubuntu community, together with Canonical, are dedicated to making the
very best open source operating system possible, one that far excels any
proprietary operating system.  To do this, we need to ensure that the process
of making Ubuntu is as effective as possible.  Moreover, we need to make the
process of making open source software as effective as possible, and then make
it easy, quick and desirable to get that software into Ubuntu.

Secondarily, Canonical's main business is the provision of premium services
built around Ubuntu.  Many of these services are based on proprietary
software, which Canonical must be able to make more quickly and at less cost
than any rival.

The word "effective" covers a multitude of concepts.  Here we mean doing the
*right* work with the highest possible *quality* as *quickly* and with as
little *waste* as possible.


Business goals
--------------

Launchpad exists to give Canonical a competitive advantage over other
operating system vendors and service providers, both proprietary and open
source.

To gain an advantage over *open source* operating system vendors, Canonical is
relying on Launchpad to:

* increase Canonical's effectiveness in making software
* grow and accelerate contributions to Ubuntu

To gain an advantage over proprietary operating system vendors, Canonical
needs Launchpad to do both of the above and:

* improve and accelerate open source software development in general beyond
  that of proprietary software so that the software in Ubuntu is better than
  the software in any rival proprietary operating system

The value flow of Launchpad can be summed up in this diagram:

.. image:: images/value-flow.svg


Who is Launchpad for?
=====================

Launchpad is aimed at many different groups of users.  They can be roughly
described as follows:

Software developers
  These are people who make or contribute to free and open source
  software. They are made up of both paid professionals and volunteers working
  in their spare time.  They vary widely in expertise and patience.  Any given
  software developer might be working on both open source software and
  proprietary software.

Expert users of software
  The sort of people who file bugs, try new releases, run the bleeding edge
  snapshot, are interested in following development plans, who help other
  people on mailing lists. Note that software developers are frequently but
  not always expert users of software.

End users of software
  People who download and install software and then use it.  These people have
  little understanding about what software actually is or how it is made.
  They use it, sometimes without noticing, sometimes enjoying it, sometimes
  hating it.

Translators
  A special class of software developer who is normally a native speaker of a
  language other than English.  They contribute to open source software
  projects not by submitting code, but by translating strings to new
  languages.

Managers
  These are managers in the broad sense of people who are responsible for the
  completion of a task and so need to know what many other people are doing
  towards that goal.  This includes release managers, project leads and
  traditional corporate project managers.  It does not necessarily mean people
  who are employed as managers.


User needs
----------

The people who use Launchpad, in whatever role, share one broad goal: “make
great software and get it to its users”.  To do this, they need:

* tools to facilitate collaboration on their proprietary and open source
  software projects
* a place to host and publish their open source software projects
* as little overhead as possible in maintaining these projects
* more contributors to their projects
* to be able to easily contribute to existing software projects

Some of our users have particular needs:

* managers need to be able to quickly get an overview of activity and
  progress for their teams and their projects
* expert users of software need to be able to give high quality feedback to
  the software developers

Further, we believe that providing tools for cross-project collaboration, we
can benefit our users by:

* giving them feedback from groups of their own users that they couldn’t reach
  before
* reducing the time and effort required to publish software to actual end
  users
* pointing them to knowledge and fixes from other projects in their network
* helping OS-driven improvements reach them code faster, and their
  improvements reach the OS faster


Conflicts between business goals & user needs
---------------------------------------------

Canonical is primarily interested in open source software that runs on Linux
or lives within the Linux ecosystem.  Thus, even though Launchpad could be an
excellent, general platform for Windows, OS X, iOS and Android based software,
our main area of focus is software that is aimed to run natively on Linux.

Canonical is much more interested in quality assurance and release management
than many open source and even proprietary projects.


What is Launchpad?
==================

Launchpad is a complete system for gathering changes from different types of
sources and collaboratively organizing them into packaged software for the end
user, delivered as part of an operating system that can be downloaded or that
comes already installed on purchased hardware.

If you start by thinking of Launchpad as a traditional software “forge” – a
web service that provides bug tracking, code hosting and other related
services – then you are not too far off understanding what Launchpad is.
However, Launchpad has many distinctive traits that combine to put it into an
entirely different category of software.

But at its core, it is best to think of Launchpad as a service that meshes
together two important networks:

1. Networks of people making software
2. The network of dependencies between software.


Distinctive traits
------------------

Launchpad is different from other "forges" in a few important ways:


Cross-project collaboration
~~~~~~~~~~~~~~~~~~~~~~~~~~~

No project lives in isolation.  Each project is part of an ecosystem of
software.  Projects must be able to interact with each other, share bugs,
teams, goals and code with each other.

.. image:: images/cross-project-collab.svg

Launchpad takes every chance it gets to show the connections between projects
and to bring the opportunities created by those connections to light.

By encompassing the entire process, all the way to operating system delivery,
Launchpad can provide a unique service: enable each contributor to focus on
the work they care about, while giving them an ambient awareness of how their
work fits into a larger picture, and providing a path by which they can
participate in other parts of that picture when they feel the need.


Front-end to open source
~~~~~~~~~~~~~~~~~~~~~~~~

Launchpad aims to be a front-end to open source.  Whether or not a project
chooses to host on Launchpad, opportunistic developers can use Launchpad to
navigate bugs, get code and send patches.  Likewise, we aim to present a
uniform interface to the projects we have.


Centralized service
~~~~~~~~~~~~~~~~~~~

Because Launchpad emphasises cross-project collaboration, and because
Launchpad aims to be a front-end to all of open source, it necessarily has to
be a centralized service rather than a product that users deploy on their own
servers.


Networks of collaborators
~~~~~~~~~~~~~~~~~~~~~~~~~

Launchpad understands that much of the human interaction around open source is
not primarily social, but rather collaborative: many people working together
in different ways toward the same goals.

As such, Launchpad highlights actions and opportunities rather than
conversations and status. It answers questions like, “what can I do for you?”,
“who could help me do this?”, “who is waiting on me in order to get their
thing done?”, “can I rely on the advice offered by this person?” and so forth.


Distributions are projects too
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Launchpad hosts Linux distributions in much the same way as it hosts projects,
allowing for developers to feel at home when interacting with distributions.


Gated development
~~~~~~~~~~~~~~~~~

Sometimes, secrets are necessary.  Launchpad understands that sometimes
development needs to be done privately, and the results only later shared with
the world.  Security fixes, OEM development for new hardware, proprietary
services with open source clients are all examples of these.


Hardware matters
~~~~~~~~~~~~~~~~

Many software developers like to pretend that hardware does not really
exist. When people distribute software as part of an operating system, they
don't have the luxury of forgetting. Launchpad understands that developers
often need to acknowledge and work around differences thrown up by hardware.


We don't care if you use Launchpad, sort of
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Many other forges exist to become more successful.  Although we love our users
and welcome every new user, Launchpad does not judge its success by the number
of users.  If one project wishes to host its development on another platform,
Launchpad acts as a front-end to that platform.


One project, many communities
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Any given project can have many distinct communities interested in it.  These
communities have different interests and different motivations, but all work
in the same project space so that they can easily benefit from each others'
efforts.


Scope
=====

Launchpad has many major components. These can be broken up into four major
areas of functionality:

1. where work is done; developers interact with other developers
2. where plans are made and reviewed; expert users interact with expert users
   and developers
3. where projects engage with their communities; developers interact with end
   users and other developers, and vice-versa
4. major supporting features

.. image:: images/scope.svg

Work
----

At the core of every software project is the actual code that makes up that
project. Here “code” is a broad term that also includes the project’s
documentation, the translatable and translated strings that make up its user
interface, the packaging and integration scripts required to get the software
installed on end user’s systems and so forth.

Launchpad is built to be able to take contributions from anybody, regardless
of how involved they are in a project. For packages, translations and code
proper we provide mechanisms to allow people to review changes from others and
then merge them into the official parts of the project.

Launchpad pulls in changes that happen in the upstreams and downstreams of a
project, whether those changes are patches to code, new translations or
packaging updates. It makes contributors to a project aware of the work that’s
going on upstream and downstream and helps them take advantage of that work.

And, of course, all work is for nothing if it does not get to the people who
might want to actually use its results. As such, project maintainers can
publish released versions of their code, any contributor can publish Ubuntu
packages to unofficial archives or even set up Launchpad to automatically
build and publish packages of latest snapshots of code.


Plans
-----

People who are interested in doing something great will need to coordinate
their work, keep track of the defects in the things they have already done and
describe the things that they aren't doing yet but wish they could.

Every software product in the world has bugs. For some projects, the rate of
incoming bugs is fairly low, and each bug can expect to receive some attention
from a core developer.  For other projects, the rate of new bugs filed is so
high that the core development team can never hope to keep up with it.
Launchpad supports both kinds of projects.

If every software product has bugs, every software user has great ideas about
how a product can be improved. Project maintainers need to get at these ideas,
evaluate them, and develop them into workable concepts.

Often, a problem is so tricky that those concerned need to have a detailed,
managed discussion about what exactly the problem is.  At other times, the
problem is easy enough to define, but there are so many solutions with
difficult trade-offs or difficult implementations that it is better to talk
about them and plan them out before proceeding with any of them. Launchpad
acknowledges that this can happen on any project, and that becoming clear on a
problem or becoming clear on the “best” solution can be helped a great deal
using tools.

Crucially, all of these different types of “plans” – bugs, specifications,
blueprints, ideas – can span more than one code base and more than one
conceptual project. These plans need to be drafted, discussed, clarified and
reviewed before work starts, monitored, evaluated and changed as work
progresses, and then the results of that work need to be checked against the
plan when the work is finished.


Community
---------

Not everything that’s done on a project is work toward a particular outcome,
or plans for how to get there. Every project needs to have some things that
are more general and stable.

Projects need to be able to present themselves to the world, confident in
their identity and communicating exactly what they are about. Project
maintainers need to be able to announce important news, such as releases,
license changes or new practices. Contributors need to get a sense of who is
working on which parts of the project. Users need to be able to ask questions,
get support and give feedback.

Contributors also need to share documentation about the project and how the
project runs. They need to be able to discuss general topics about the
project.

Launchpad supports all of these things, and also makes it clear how any
project fits into the broader ecosystem of projects. It shows which projects
are upstreams or downstreams, which projects are affiliated with other
projects, which projects share contributors with other projects and so forth.


Supporting features
-------------------

Launchpad has many major areas of functionality that are best considered as
“supporting features”: APIs, migration services, privacy, the mail UI,
synchronizing with external systems.


New World
=========

When Launchpad is really doing all of these things and doing them well, the
world of open source software will be significantly changed.

Patches will no longer lie decaying in someone else’s bug tracker, waiting to
be noticed. Instead, they will all be synced into a central code review system
and queued for review and approval.

Instead of a distribution tracking one set of bugs and upstream projects
tracking their own set of sometimes duplicated bugs, both upstream and
downstream developers can seamlessly accesses both sets of bugs.


The story of a bug
------------------

*Arnold* writes software for a living, and he runs Ubuntu on his desktop. He
wishes he could contribute to open source, but he doesn’t have much spare
time, and when he gets home from his job the last thing he wants to do is
program. However, the spirit of willingness is there.

One day, Arnold notices that Tomboy loses his formatting if he alt-tabs at the
wrong time. Arnold knows that a well-filed bug report is a thing of beauty to
most programmers, so he decides to spend a few moments to file a bug against
Tomboy.

Rather than search the net to find where Tomboy tracks its bugs, Arnold uses
Ubuntu’s built-in bug filing mechanism. It asks him a bunch of questions,
invites Arnold to write his bug report and then files the bug on Launchpad
against the Tomboy package in Ubuntu.

*Becca* has been dabbling in Ubuntu contribution for a while, mostly by
helping new users solve their problems or turn them into good bug reports. She
notices Arnold’s bug, sees that it’s well written and thinks that it would be
easy enough to test against trunk. She opens up the Tomboy source package in
Ubuntu and sees that there is a known-good daily build of Tomboy’s trunk
hosted in a trusted user archive. Becca installs Tomboy from this archive and
tests to see if the bug is still there in the latest version of the code. It
is. Becca sees this, opens up the original bug report and clicks a button to
forward the bug to the upstream bug tracker.

*Carlos* is one of the Tomboy developers. He sees the bug in the tracker, sees
that it has been tested against trunk, realizes that it’s an annoying bug
that’s easy to fix and decides to fix it. He does the fix, applies it to the
Tomboy trunk and marks the bug as fixed.

At this point, both Arnold and Becca are notified that the bug is fixed in
Tomboy trunk, and that they can try a version of Tomboy that has the fix by
using the known-good daily build archive for Tomboy. They are warned that this
is dangerous and may cause data loss, but they are also told how they can try
the bug fix for free using a cloud-based Ubuntu desktop. They both try the
bug, see that it’s fixed, and are happy, albeit a little impatient for the fix
to be actually released and part of stock Ubuntu.

Meanwhile, *Dalia* is an Ubuntu developer who takes a special interest in
desktop productivity applications like Tomboy. She checks on the Ubuntu source
package for Tomboy from time to time. The last time she checked, she saw that
quite a few bugs have been fixed in trunk but not yet released. Since she
knows the Tomboy release manager from long hours of IRC chat, she contacts him
and gently suggests that he do a release.

*Edmund*, the Tomboy release manager, takes Dalia’s hint well and realizes
that a release is way overdue. He makes a release of Tomboy following his
normal procedure.

Launchpad detects that Tomboy has a new, official release and alerts
interested distribution maintainers that the release has been made and now
would be a good time to package a new version. Dalia packages up a new
version, requests that an Ubuntu core developer sponsor the change and then
waits for the new version to be uploaded. Dalia also uploads the fixed version
to one of her personal archives so that others can easily get it without
waiting for the next release of Ubuntu.

*Fiona* the Ubuntu core developer sees Dalia’s patch in the sponsorship queue
on Launchpad, notes that it’s all good and then uploads the patch to the
official Ubuntu archive. (Fiona might also choose to upload the patch to
Debian).

Launchpad sees that this upload fixes a number of bugs, including the one
originally filed by Arnold, and automatically includes those bugs in the list
of bugs that will be fixed by the next release of Ubuntu.

Two months later, the next release of Ubuntu is actually released. Arnold
upgrades on release day, and tries out Tomboy to see if his bug was really,
actually fixed. It is, and all is right with the world.


Glossary
========

Upstream
  A software project itself, as opposed to the packaged version of a software
  project that is included in a distribution. Note, can also be used as a
  relative term, e.g. “Debian is upstream of Ubuntu”.

Downstream
  The opposite of an upstream. Can be used to refer either to a packaged
  version of a specific software project, or the entire distribution where
  that package occurs.


References
==========

* `Product values <values.txt>`_
* `Feature checklist <https://dev.launchpad.net/FeatureChecklist>`_