Bespin Reboot 2009

In the months since Bespin's public release and growth in features and open source contributions, we have learned about Bespin's strengths and weaknesses. A good deal of the project is working quite well, but over time we have found some needs that are not being addressed well:

1. Some users need at least a portion of Bespin to be treated more like a "product" than an experimental project
2. With no formal plugin mechanism, new Bespin behavior needs to be integrated with the core Bespin code to be useful.
3. The "embedded" version of the Bespin editor is not handled like a first class citizen when it comes time to make releases, and yet it is a popular part of the project.
4. You can't embed two Bespins on a page, because of the use of globals (bespin.get, bespin.publish, etc.)
5. The core needs more automated tests to help ensure that we can make releases quickly without breaking things for people who are dependent on it.
6. The documentation on the wiki can be out of date relative to the current state of the code.
7. In the client, there is too much state spread over too many different parts of the UI, rather than a consistent worldview that the whole client can participate in.
8. Writing a full-featured and tested UI toolkit is a good deal of work, and that's not where we want to spend our time.
9. For a programmer's editor, powerful and flexible keyboard handling makes a big difference in the user experience.

The "Reboot" is a significant refactoring of Bespin to fix these issues. Note that it's not a rewrite, much of Bespin is just fine. Also note that the focus is on the client and not the server at this time.

What does a Reboot look like?

This Reboot of Bespin looks like this:

• Thoughts about what needs to be done for this project
• Some preplanning and getting infrastructure ready
• A one week "spike" to try out our ideas for where Bespin needs to be
• A few weeks that follow where all of Bespin's features are ported to the new structure and some initial new features are added
• The first Bespin Reboot release once a sufficient amount of Bespin is running again

High level principles for Bespin

What are the guiding principles for Bespin?

• Platform for developer tools
• Embedded component is a first class citizen
• Provide a fantastic editor user experience
• Support for local file access and multiple backends
• Giving users 'social coding' to inform of others' work and avoid duplicated effort
• Providing a simple but powerful UI using a graphic-assisted command-line

What are tactical things we want to fix?

What have we learned from Bespin that we don't want to mimic:

• Use a framework
• Events are great, but not too many. They're for saying that something happened, not for requesting action
• One system for keyboard handling
• Embedded component must be a first class citizen else it gets left behind
• Tests, tests, tests
• Prototypes, prototypes, prototypes
  • We jump to implementation too fast
• Plugins, plugins, plugins
• Documentation, ...

Reboot "Event"

The Bespin Reboot will start with a bang:

• New Mercurial repositories will be created for the client and server code
• Some infrastructure code will be put in place
• The week of September 28th will be the "Reboot Event", where we run an experiment to "pour" the Bespin code into a new SproutCore-based UI. We will try to quickly determine if this is the right path.
• The new code will be built with a much more robust plugin model, with many of Bespin's parts themselves residing in plugins
• More unit tests from the start
• More documentation created as we go along (living in the repository, versioned either in the code or with the code)

Given that this is just a one week period and there's going to be a bit of exploration and learning going on, we expect the output of this week to be a usable Bespin but not one that has all of the current features of Bespin or all of the key features needed as part of the reboot.

We are also not looking to significantly alter Bespin's user experience at this time. This is more about building the right structure for Bespin to grow.

Reboot Roadmap

The exact schedule for the weeks that follow the Reboot Event will depend on what is learned during the event itself. Specific items for post-Reboot Event:

• Finish porting all of Bespin's current features over
• New keyboard manager which can handle user and plugin defined keymappings.
• Easy ways to share and discover/install plugins
• Ability to edit files on your local computer (use Bespin as your primary day-to-day editor!)

What is our software development process?

Our development process is changing a little bit based on what we've learned. For one, we will internally think of things as "core" or "experimental". Bespin core parts are going to be held to a much higher standard in:

• code review
• testing
• documentation

These are the parts that other people can reliably build upon. The experimental parts are just that: things we're trying out. This is still a Mozilla Labs project after all, and we anticipate giving things a whirl that may or may not work out.

We have also found that we've sometimes spent too much time chasing ideas that don't pan out. Going forward, we will try using higher fidelity prototypes that we can use to get feedback.

How do we work with the community?

We expect that the introduction of a full plugin system will open the doors for a tremendous amount of new community contribution, with an extremely low barrier to entry. We're really excited about this aspect.

Also, we (at Mozilla) have not always been good at getting code contributions into the main repository. We are improving on this:

1. Through better use of Mercurial and Bugzilla (documented so that all contributors can easily make use of these tools)
2. Through plugins which don't require being in the main repository at all

Note that on the one hand, better use of hg and bugzilla will help, we are also adding more stringent requirements for getting code into the "core" of Bespin so there is a balance being sought.

Embedded Editor

The goal of the embedded editor is that it can be a useful component for anyone to plugin to an editing, and specifically code editing use case.

You should be able to:

• Hot link to bespin.mozilla.com/embed.js and be ready to play
  • Should you be able to ask for a version? b.m.com/embed.js?v=2.3
• You should be able to copy the component down to your server for use
• A user should be able to have his settings and info come with him across uses
  • Developer can embed.useSharedSettings(false);
  • How does this work in practice? b.m.z vs. custom .js
• Be able to tie into Bespin services via the embed API; E.g.
  • collaboration
  • command line
  • plugins (collab and command line can be plugins of cos)
  • backend store (use Bespin editor component and save to backend)