Camino Meet-up:2007:Notes

What follows is the abridged version of the notes taken at the 2007 Camino Meet-up in Mountain View, California. Note that any stats listed are as of June 15, 2007.

Attendees

cl, froodian (1 day), hwaara, jeff, josh, kreeger (1 day), ludo (1 day), peeja, pinkerton, smorgan, ss

Mission Statement

There has often been discussion about what Camino's focus is. We haven't clearly stated the mission of the Camino Project previously and thus wanted to spend some time focusing on a mission statement. After going through several iterations of a mission statement, we finalized on the following:

"Camino is an open source web browser developed with a focus on providing the best possible experience for Mac OS X users."

What We Aren't

Now that we've determined our mission statement, we know a lot about what we aren't.

• We're not a general purpose internet utility (i.e., an RSS reader, email client, news reader, etc.).
• We're not a complex application requiring documentation to understand.
• We're not everything to everyone (not simply Firefox with Cocoa controls)
• We're not Steve Jobs' browser
• We're not a development platform

Motivations

There are several motivations we have for creating Camino and continuing work on it.

• We have a very loyal user base of ~350,000 users, most of which are pre-1.5 (~150k downloads of 1.5 so far)
• We can control our own destiny and aren't controlled by external forces
• We believe that open systems are better than closed ones
  • Other browsers are controlled by large corporations, Camino is entirely volunteer and open source.
• We can innovate and differentiate
  • Innovate with things like Tabsposé
  • Differentiate with things like better tab handling, single window mode, better pop-up blocking, ad and flash blocking
• We can be more nimble
  • Not tied to OS schedules
  • We can (and should) release early and often
  • Shorter time to market
• Broader support
  • More OS versions
  • We care about people who have been left behind
• We're not evil
  • There's no hidden agenda
  • We're not gold diggers and aren't in it for the money
  • We just want to make good software

Feature Planning for 1.6

The following features were discussed for Camino 1.6 and given various priority ratings.

• P1: Scrolling Tabs
  • P1: UI
  • P1: Menu on side
  • P2: Animation
  • P?: "One past" tab selection
• P1: Software Update
• P2: Draggable Tabs
• P2: Breakpad
• P2: Extensions folder (global and user)
• P2: Undo close tab (reopen tab)
• P2: Firefox in user agent
• P3: Multiple tabs in home page
• P3: Search engine editor
• P3: Tabsposé
• P3: AppleScript support

Release Plan for 1.6

The following release plan was created for Camino 1.6. It should be noted that this is a tentative plan and is subject to change.

• Release date: End of August 2007
• 1.6 String Freeze: Beginning of August (3-4 weeks prior)
  • Will move freeze for P1s, maybe for P2s depending on progress
  • Will not move freeze for P3s
  • Need special queries for nib changes
  • Should we move string files to UTF-8?

Summer of Code Updates

Tabsposé: Some progress made; only a week or two in. Only shows a blank screen now (switches out views).

AppleScript: Should take less time than expected to write dictionary. Windows and tabs are about done now. Next up are bookmarks and history.

Camino 2

Motifs

For Camino 2, it'd be nice to have a motif to base it on, both at a development level and a marketing one.

• Awesomeness! (For every release, really. :) )
• Get Gecko out of UI layer
  • Removing Gecko from the UI layer will make it easier for new developers to get started
• Improve l10n communications and process

Caveats

With the number "2", it's easy to go crazy and have a bazillion features. We should keep it simple and easy-to-use since that's what we've always been and our users expect. (See also: mission statement) For Camino 2, we should focus on a subset that's reasonable in order to ship on a decent schedule.

Feature Brainstorm

Note: The following list of features are simple a list of ideas thrown out as possible features for inclusion in Camino in the future. None of these have been settled on for true development for any future release of Camino nor have any been specced out.

• P1: Gecko 1.9
• (Carry over from Camino 1.6 list)
  • P1: Tabsposé
  • P1: Draggable tabs
  • P1: Breakpad
• P1: RSS to web readers (Google, Bloglines, My Yahoo, etc.)
• P1: Find bar for "type-ahead find"
• P1: Store multiple username/passwords per domain
• P2: Improved AppleScript support
• P2: PDFKit for inline PDF
• (Carry over from Camino 1.6 list)
  • Extension system
  • Undo close tabs
  • Multiple tabs as homepage
  • Search engine editor
• Hide status bar
• Localizable strings in chrome
• Tags in bookmark management
• Leopard-style UI for bookmark manager
• Bookmark sync (.Mac/iPhone)
  • Requires rewriting backend as plugins
  • Our default system becomes a plugin
• Email webpage
• Send email to URL bar (?? Did I mean to write "from" here?)
• UI Refresh
• Resolution independence
• Full screen mode
• Activity viewer
• JS Console
• Pause/resume downloads between sessions
• Improved feed support from core
• Form autofill (remember each form entry in single line inputs and allow for autofilling of them)
• View source w/o reload
• Auto-update for adblock
• Rewrite history using SQLlite
• Chromatabs
• Anti-phishing
• Add extended attributes to downloads
• Better accessibility

Architecture

For Camino 2, we're going to have a much better Gecko architecture to build on. New core improvements will get us Quartz rendering, better plugin performance, and improved form controls. Unfortunately, the minimum version of trunk will likely be Tiger (10.4). This takes out a large portion of users for us.

There's also something to be said for being Leopard (10.5) only at this point. That would allow us to focus on developing features fast and not worrying about maintaining compatibility with older OSes. This idea was rejected, however. Users on older OSes (of which 10.4 will be one) deserve support from us.

One idea is to keep the same feature set on the branch (where possible; architecture changes may make this impossible in some situations) and release a parallel Camino 1.7 for Panther users. This, however, would put a lot of burden on the development and QA teams.

Additionally, we need to remove Gecko from our UI layer. This will make it much easier for developers to work more on Camino. This involves pref migration to NSUserDefaults and Obj-C wrappers for Gecko. Doing so will also provide flexibility in the future with regards to rendering engine.

Camino 2 will also be a chance to move from XPFE to Toolkit and get any benefits there. We might also think about becoming a XULRunner appliation, though that's less likely for Gecko 1.9 and might be reserved for Gecko 2.

Build

For Camino 2, it makes sense to move our project file and build system to XCode 2.5 and 3.0. Reports state that XCode 3.0 files may be read, built, and modified by XCode 2.5, which provides greater flexibility for developers. Additionally, it's been said that the two can run side-by-side.

Webkit

(And now, the moment readers of this document have been waiting for!)

First off, why discuss Webkit at all?

It's quite clear that Webkit has an upwards trajectory, both in terms of speed and compatibility. Can that same claim be made for Firefox/Gecko? Are you sure? Safari on Windows and the iPhone definitely pushes that forward even more. Both Nokia and Adobe (Apollo) are using Webkit in a big way so consumers other than Apple are starting to have a say, more and more.

Gecko has a lot of pitfalls. There's a *huge*, *steep* learning curve for new developers. Building it takes forever. Not everyone has a Mac Pro. It can take up to 3 hours to build Camino on a G4 laptop right now. Some of this might get solved with XULRunner, but it'll still be bad. Additionally, there are very few Mac devs looking at Gecko. This results in few Mac-specific features, minimal OS integration (especially moving forward with grammar checkin and dictionary support), and horrible accessibility support.

Webkit has a lot of benefits:

• It's fast
• It ships with the OS, which would reduce download size.
• It's much more approachable and easier to understand
• Very nice, Cocoa-centric embedding API
• Open source, just like Gecko
• Better plug-in support
• Better widgets (standard text widgets and selects)
• Better OS integration
• Very important to Apple (not going away; iPhone, etc)
  • That means it's in active development
  • Hyatt approved

However, with those benefits comes a few pitfalls:

• Hyatt approved
• Infrequent releases, which are tied to the OS
• Generally, new features aren't backported to older OSes, which robs us of a big differentiator
• It doesn't have support for all of our features
  • (Many can be implemented on top of Webkit, e.g., pop-up whitelists)
• Apple withholds most of their changes and new features for Steve-notes
• We'll need a new motto. ;) ("Mozilla Power, Mac Style.")

It should be noted that right now compatibility isn't that good with Webkit. Some sites (even Google sites) have a reduced experience using Safari. Even others don't allow it. Of course, as mentioned above, since Apple doesn't backport any fixes to web compatibility, this can create a worse experience for users on previous OSes. This is a *huge* point to Gecko.

If we're going to do this, when and how? It would definitely have to be post-2.0, but we'd have to move fast. The easiest thing to start doing is removing Gecko from the UI layer, which we already intend to do for other reasons. We'll need to evaluate features that are not in Webkit which we get for free (or easily) from Gecko (e.g., core support for pop-up blocking, cookie management).

But what can Mozilla do for us in a lot of these respects? Overall, we've been treated poorly, despite the Mozilla Foundation's mission statement. Various individuals in the community at even at the Foundation itself have been helpful, but we get the strong notion that we're unsupported. The Corporation, by design, is antagonistic. Even with the benefits we may get, the Mac team is generally understaffed from what we'd like it to be. However, there are many benefits which we receive for free from Mozilla, specifically a shared infrastructure (bug system, tinderboxen [kind of], Talkback/Breakpad, CVS, benefit of cross-platform bug fixes).

In the future, there'll be even more changes. Gecko and Firefox will be moving to a new repository and we're not going with them (not our choice). Gecko will become a separate pull, which gives us even more reason to work on separating the UI layer. There will also be a (mostly) required move to XULRunner, for better or for worse. Word on the street is, it's better, but it'll definitely be a lot of work and we haven't yet evaluated it.

After some discussion, we resolved to keep Webkit on our minds, but put it aside until some of the above issues have been addressed. One of the major issues we need addressed is web compatibility. This topic will probably be discussed again in the future.

Recruiting

One of the issues we've had trouble with in the past is recruiting. This seems to be a recurring theme and something we need to work on. We need more developers and a larger QA team. People who join #camino need to be encouraged more; helping newbies and nurturing the community will be a large benefit to us. Who knows, they may become our top developer!

Marketing

Right now, we have very simple forms of marketing including press releases, a few interviews, and working with various magazines and weblogs to get reviews and coverage. In the future, we want to be more proactive about marketing. Getting the word out is very important. We need to generate more interviews and start working with some distribution partners.

Some of the future marketing/PR we're planning on doing involves advertising, sponsoring events (like at WWDC), and other things as needed. We'll be reaching out to some magazines in the future to get more traditional coverage as well.

General Improvements

There's a lot to be said for being more transparent with our decisions and planning. In the future, we should try to move more of our planning to the wiki. This will allow others to see it and allow better communication among our own dev team.

We also want to start using the Google Group (mozilla.dev.apps.camino) for capturing decisions. There are times when a bug says "closed per IRC" but doesn't have a strong description of what that means. We should be putting these decisions in the newsgroup so others can understand why it was made. This will also increase discussion for developers who might not use IRC as much or are in different timezones.

Other Issues

At the meet-up we also discussed some minor things, such as changing the wording of some pref panes, being more vocal about our projects history and making it more visible, and upping the total number of votes in the Camino product in bugzilla from 5 to 100. Those things are at various stages, with the last one (votes) being completed.