Sunset Plan for Thunderbird 2.0.0.x

[Dan Mosedale]

Thunderbird 2.0.0.24, made available on March 15, 2010, is the last
planned security and stability update for Thunderbird 2.0.0.x.

The latest official versions of Thunderbird 2.0.0.24 can be downloaded from
http://www.mozillamessaging.com/en-US/thunderbird/all-older.html
Thunderbird 3.0.x was released on December 8, 2009. Mozilla encourages
users to upgrade to the latest version of Thunderbird 3.0.x.

The latest versions are available as free downloads from
http://www.GetThunderbird.com/

For Thunderbird Distributors

Enterprise-oriented distributors and ISPs are encouraged to download and
evaluate Thunderbird 3.0.x or Thunderbird 3.1. Several new features are
being included in Thunderbird 3.1 to further assist your users in
upgrading from Thunderbird 2.0.0.24 to Thunderbird 3.1. Targeted
release date of Thunderbird 3.1 is summer 2010.

The latest pre-release versions of Thunderbird 3.1 are available as free
downloads from

http://www.mozillamessaging.com/en-US/thunderbird/early_releases/downloads/

While the Mozilla product strategy continues to focus on the individual
end-user, Mozilla will continue to work with downstream
enterprise-oriented distributors and support vendors to enable extended
support for otherwise legacy releases.

Our development plan is available at
https://wiki.mozilla.org/Thunderbird:Thunderbird_Post_3.1_Plan

_______________________________________________
tb-planning mailing list
tb-pl...@mozilla.org
https://mail.mozilla.org/listinfo/tb-planning


--
Subscription settings: http://groups.google.com/group/tb-planning/subscribe?hl=en

[Kent James]

On 4/23/2010 5:47 PM, Dan Mosedale wrote:
> While the Mozilla product strategy continues to focus on the
> individual end-user, Mozilla will continue to work with downstream
> enterprise-oriented distributors and support vendors to enable
> extended support for otherwise legacy releases.

I've seen precious little written on who the Mozilla product strategy is
focused at, so I appreciated this little incidental insight.

As part of the understanding of the next steps for Thunderbird and MoMo,
I would really appreciate more commentary on the market segments that
people see exist out there, and what are the primary market segments for
Thunderbird.

I assume most of you are familiar with a "market segment", but if not I
would describe it very briefly as a distinct subgrouping of your
existing or potential customers, that share some characteristics in
common, and benefits from being understood and targeted as a group.

I will admit I have very little clue on what the actual market segments
are for Thunderbird, or what the perceived segments are. But at the risk
of truly proving my ignorance, I will make a few guesses:

1) Recent discussions on m.d.a.t have made it clear that colleges are a
distinct market segment.

2) The home Windows user that does not either own or want to use
Outlook, and typically would have used Outlook Express.

3) Small, cost-sensitive organizations that do not use Exchange Server.

4) A small organization, perhaps as part of a larger organization, that
uses a diverse mix of Linux, Windows, and Macs. (Differs from 3 in being
driven by technical diversity rather than cost).

5) User on a low-cost second computer, perhaps a netbook or home
computer, that interacts heavily with a normal Exchange/Outlook business
world, perhaps mixed heavily with personal use.

6) The Enigmail user - I don't understand them, but it is a very popular
yet technically sophisticated extension, that I cannot see any of the
previous market segments wanting. Who are they?

7) I keep getting hints that there are a few large organization
deployments that have traditionally received direct support from
Mozilla. What motivates them to do this, if they exist?

Obviously you could subdivide these forever, but a typical organization
is best served by seeing the world as 5 - 10 market segments that they
can target.

What segment is the MoMo team targeting? As an example, my EWS work
targets groups 4) and 5).

Kent James

[Archaeopteryx]

A few pain points with this.

1) IIRC, there was the policy of an at least six months upgrade window,
so delay the message by a month.

2) Thunderbird 3.1 has not been released yet but is mentioned in the
message. 3.0 isn't linked in the distributor notes, but 3.1 isn't and
its pre-release status isn't mentioned the first time you talk about 3.1

3) Please add a how-to page how to prevent the user interface changes
for the distributors, they probably don't want to tell every user how to
switch from Smart Folders to All Folders or how to see again the message
count in a folder.

Archaeopteryx

[David Bienvenu]

On 4/23/2010 9:58 PM, Kent James wrote:
> 6) The Enigmail user - I don't understand them, but it is a very popular yet technically sophisticated extension, that I cannot see any of the previous market segments
> wanting. Who are they?

technically sophisticated, privacy-conscious users. But you kinda knew that.

>
> 7) I keep getting hints that there are a few large organization deployments that have traditionally received direct support from Mozilla. What motivates them to do this,
> if they exist?

In the past, I would say they have been motivated by up front cost, and the ability to customize the client (e.g., lock down features) so as to drive down the total cost of
ownership (lower ongoing support costs).

- David

[Ben Bucksch]

On 26.04.2010 17:33, David Bienvenu wrote:
>> 7) I keep getting hints that there are a few large organization
>> deployments that have traditionally received direct support from
>> Mozilla. What motivates them to do this, if they exist?
>
> In the past, I would say they have been motivated by up front cost,
> and the ability to customize the client (e.g., lock down features) so
> as to drive down the total cost of ownership (lower ongoing support
> costs).

As for the German Office of Foreign Affairs, it's

* costs reduced, both license and maintenance (Debian package
management)
Since switching to Open Source, this office has by far the lowest
IT costs of all German offices (half of the average) per desk.
* removing dependence on a single vendor (Microsoft)
* ability to customize and change and make bugfixes themselves (and
they have)
* open source values (community, security, privacy etc.) - Open
Source is very popular here

[Kent James]

In trying to classify these as market segments rather than individual
customers, do you think it would be fair to way that there are really
two segments? One is driven primarily by cost of the email client, and
the other by a philosophy (or requirement) of using open source software
(which would probably include concerns for reducing dependence on
Microsoft)?

Analysis of market segment is not a precise science, and ultimately is
determined by what is useful in understanding your clients.

[Ben Bucksch]

On 26.04.2010 19:18, Kent James wrote:
> do you think it would be fair to way that there are really two segments?

I think there are 4 basic market segments:

* private users, mom and dad
* private user, techie
* small companies
* big (>1000 seats) companies

And these have very different needs.

> One is driven primarily by cost of the email client, and the other by
> a philosophy (or requirement) of using open source software (which
> would probably include concerns for reducing dependence on Microsoft)?

No, a change as big as this (big organization, rollout to many thousand
users) is usually driven by several factors. So also in the example I
mentioned: both of these were a factor.

[David Ascher]

Kent, great questions.

My analysis on this market segmentation question is fairly coarse, but maybe useful. This is mostly derived from anecdotal information rather than great data, because solid analytics are really hard to come by.

I believe the two largest segments for current users of Thunderbird are:

1) "Institutional" or "enterprise" deployments, such as universities and governments, who deploy Thunderbird primarily because it's open source, and gives them a traditional email client (rather than webmail) which does not tie them to a proprietary vendor. It's hard to tell how many large businesses use Thunderbird -- I suspect most of our corporate users are outside of North America, due to the different relationships with Microsoft in different geographies. (Note that for most universities I know about, desktop clients are primarily allocated to faculty & staff, and students, more mobile, use webmail).

2) SOHO/SMB-type users for whom Thunderbird is the preferred choice because of a combination of: a) history (many Thunderbird users picked Netscape years ago), b) customization options, including add-ons, myriad preferences, c) an affinity with Mozilla and the values of openness, user control, etc.

There are other groups in my mind (and I realize my breakdown of the market is similar but slightly different than yours), but the above two, I believe, account for most of our users. This is a very gross generalization, and indeed many educational users also like the Mozilla mission, and there are people using it as a "home email client" as a complement to their Outlook usage at work, etc.

Still, the dichotomy above is I think quite interesting, and portentous (which is a word I wouldn't normally use except how often does one get a chance?). In particular, I see the above two segments wanting different things out of an evolving product.

Institutional admins have a job that I remember well (I used to be the mail admin for brown.edu, dealing with about 6k users). In many ways, success comes from establishing enough control so that users don't cause too much havoc, because there's always way more users than there are hours to help them. In particular, those deployments of desktop software need things like remote management, more or less locked-down setups, centralized configuration, multi-year roadmaps, SLAs, second-tier support arrangements, interoperability with systems like Exchange, blackberries, etc. The systems they want Thunderbird to integrate with tend to be internal systems like inside-the-firewall calendar servers, LDAP servers, CRMs, Exchange servers, etc. (Educational institutions in some ways have it even worse than corporate deployments, because their user populations resent central control, and their budgets are often tight). These deployments tend to prefer slower product evolution.

SOHO/SMB users tend to be more like "consumers". They get software straight from the "vendor" (or from their Linux distro), do security updates as prompted, relish the ability to be "in charge" of their software life. They tend to want to integrate with the internet rather than the intranet, and many are exploring varieties of communication systems from Facebook to Twitter to Skype, etc. They tend to live more and more on the web, and expect more and more all of their software to integrate with the web. These users range in their attitude towards change and risk, ranging from early adopters to more conservative users (most of us actually have different attitudes towards different things -- e.g. I like my cars and clothes old, my web toys shiny and new).

A couple of additional meta-points:

 - Both market segments periodically evaluate their use of desktop software in a world where the web is becoming more potent daily, but where their feeling of control over the software they use on the web is being challenged as well. I think we need to build tomorrow's software with as full an understanding of these factors as possible. I can talk forever about that, but it's a bit off-topic.

 - Mozilla's culture, at least since the inception of Firefox, and as described by the Mozilla Manifesto, is user-centric, not business-centric. When having to choose between something that is better for people or something that is better for organizations, we routinely choose the former. I'm proud of that and I don't see that changing.

 - I believe it is easier to get unpaid contributors to projects that are aimed at individual users; I believe it is easier to build businesses making software for businesses. All other things being equal, of course (_Ceteris paribus_ as philosophy teachers say).

 - Mozilla's greatest successes to date center on making the web accessible, fun, useful. I don't think that's an accident. I think the web was built to be open, and as a result, a small group of people can have a large impact with it. I don't know anyone who'se been able to have similar scale impact in the world of traditional messaging stacks, for a variety of reasons.

My thinking about where we should go from here is evolving, but my current thoughts are:

 - Mozilla Messaging will be exploring possible new features for Thunderbird primarily through add-ons, so that we can iterate fast, and take risks which we can't take with trunk. As an example of the kinds of things I'm thinking about, see Shane Caraveo's blog: http://shane.caraveo.com/ -- he's been getting familiar with the codebase, and spinning up a few experiments. Aspects that I'd like us to explore include making Thunderbird more competitive for the "SOHO/SMB/consumer" market, including integration with web-based services, including Weave for sync, etc.

 - We'll also keep working on the "platform" aspect of our codebase, so that both we and others can experiment more easily. That includes things like keeping up with the work that the Jetpack team is working on, and likely building more bits of componentry into the platform.

 - I don't think it would serve our mission to set up Mozilla Messaging as an enterprise-focused business, and I don't think we have the DNA for it. However, maybe others can fill in the gap. To explore that, we've been thinking about setting up an email list where admins of large Thunderbird deployments can drill into the issues which get in their way, and, I'm hoping, find companies, add-on authors, and contributors who can help them. The conversation about autoconfig in universities was interesting, but I think we can have maybe less virulent versions of those discussions in a better defined forum, and where I can point people who might be able to help.

 - As an aside, I'm really interested in your work on EWS. I think there are lots of opportunities there, especially for someone who's interested in building a business around it. I also think it's potentially a very large project, and has definite technical risk, which is why I like the fact that you're poking at it to understand those areas of risk.

--da

[David Ascher]

uh, no, i have a call at 1:30

[Kent James]

On 4/26/2010 11:05 AM, David Ascher wrote:
> (Note that for most universities I know about, desktop clients are
> primarily allocated to faculty & staff, and students, more mobile, use
> webmail).

> SOHO/SMB users tend to be more like "consumers".

> - Both market segments periodically evaluate their use of desktop
> software in a world where the web is becoming more potent daily

> - Mozilla's culture, at least since the inception of Firefox, and as
> described by the Mozilla Manifesto, is user-centric, not
> business-centric. When having to choose between something that is
> better for people or something that is better for organizations, we
> routinely choose the former. I'm proud of that and I don't see that
> changing.

> - Mozilla's greatest successes to date center on making the web
> accessible, fun, useful.

> - I don't think it would serve our mission to set up Mozilla
> Messaging as an enterprise-focused business

If I may summarize your views in a way that you will probably object to,
but I sincerely believe is accurate, it is that 1) there is no future in
a standalone email client like Thunderbird for the individual user, and
2) MoMo must remain committed to the individual user, therefore 3)
Thunderbird does not make any sense as a flagship product for the future
world that you see for MoMo. That's what makes it really hard to make
comments on directions for Thunderbird, as it does not really fit into
the strategic future of MoMo - your product is RainDrop.

It seems to me that MoMo needs to either clearly articulate the
technical direction that Thunderbird could take to morph it into a
product that matches your strategic vision - or else agree that the
individual user is not the ultimate target of Thunderbird, and let it
develop into a product focused on various organizational or professional
market segments. My fear is that you will hold on to Thunderbird as an
individual email client for too long, and in the process allow any
possible strength it might have had as an organizational product (or
working professional-focused product) to be regressed into oblivion.

I personally am not pessimistic about the role of a standalone email
client for the individual, but I think that there needs to be some major
changes in focus, understanding what, exactly, a standalone client
offers over a webmail client, and designing the product to optimize
those advantages. As a unifying concept, I would use information
defragmentation (see
http://mesquilla.com/2009/01/27/information-fragmentation-its-the-enemy/
for a personal client. (That is where my heart is, but I also agree with
your assessment that it is much easier to imagine an income model
focused on business-oriented market segments than personal-oriented
market segments. So I focus there with my EWS work.)

So in conclusion, I think that Thunderbird badly needs a carefully
articulated strategic vision, organized around a few target market
segments where the product could offer some compelling advantages over
the available alternatives.

I appreciate your comments so far, and look forward to hearing more
about the vision for Thunderbird that the MoMo team develops.

[Andrew Sutherland]

On 04/26/2010 02:53 PM, Kent James wrote:
> If I may summarize your views in a way that you will probably object
> to, but I sincerely believe is accurate, it is that 1) there is no
> future in a standalone email client like Thunderbird for the
> individual user, and 2) MoMo must remain committed to the individual
> user, therefore 3) Thunderbird does not make any sense as a flagship
> product for the future world that you see for MoMo. That's what makes
> it really hard to make comments on directions for Thunderbird, as it
> does not really fit into the strategic future of MoMo - your product
> is RainDrop.

I read it as: The enterprise is not a top priority, individual users are.

Not sure where you got the 'the sky is falling' for Thunderbird in the
form of Raindrop from.

Andrew

[Andrew Sutherland]

On 04/26/2010 02:53 PM, Kent James wrote:

> If I may summarize your views in a way that you will probably object
> to, but I sincerely believe is accurate, it is that 1) there is no
> future in a standalone email client like Thunderbird for the
> individual user, and 2) MoMo must remain committed to the individual
> user, therefore 3) Thunderbird does not make any sense as a flagship
> product for the future world that you see for MoMo. That's what makes
> it really hard to make comments on directions for Thunderbird, as it
> does not really fit into the strategic future of MoMo - your product
> is RainDrop.

I read it as: The enterprise is not a top priority, individual users are.

Not sure where you got the 'the sky is falling' for Thunderbird in the
form of Raindrop from.

Andrew

[Ben Bucksch]

On 26.04.2010 23:53, Kent James wrote:
> If I may summarize ... 1) there is no future in a standalone email

> client like Thunderbird for the individual user

I don't see how you draw that conclusion. A desktop client is essential
for privacy of the individual and private mail. With webmail (or IMAP),
love letters, communication with wife & children, or business
communication, are only protected by a password. There's something
fundamentally flawed when third parties have insight into such
inherently private communication. In fact, there'd be no privacy at all
anymore. I therefore see open-source desktop messaging applications
(incl. Thunderbird as one of the most popular ones) as a critical and
indispensable for the communication infrastructure.

> understanding what, exactly, a standalone client offers over a webmail
> client

Data sovereignty.
(And today, speed and desktop integration and GUI comfort.)

> So in conclusion, I think that Thunderbird badly needs a carefully
> articulated strategic vision

I gather (in fact, you said) that you'd like Thunderbird to support the
enterprise better. The great thing about open-source is that there's not
one party - not even MoMo - which determines the sole direction of the
product. (I wish that idea would manifest itself more in the actual
day-to-day project organization, but that's another topic.) You are free
and welcome to go ahead and improve Thunderbird for enterprise markets
(hopefully you'd contribute the changes back to Mozilla). I did the same
in many cases, and in turn profit from changes from others. It's that
which makes up the greatness of open-source.

Many different needs some together and are fulfilled, sanding off the
corners. In many cases, the requirements are from all areas anyways, and
something that helps novice private users also helps the novice users in
the enterprise, and things that help enterprises also help power users,
and power users advocate at all other market segments. It's these
"synergies" which make long-term successful products.

[Ben Bucksch]

On 27.04.2010 00:10, Andrew Sutherland wrote:
> Not sure where you got the 'the sky is falling' for Thunderbird in the
> form of Raindrop from.

Well, "raindrop" means that part of the "sky is falling", no?

[David Ascher]

On 4/26/10 2:53 PM, Kent James wrote:
> If I may summarize your views in a way that you will probably object
> to, but I sincerely believe is accurate, it is that 1) there is no
> future in a standalone email client like Thunderbird for the
> individual user,

I don't believe 1). I think that there are a variety of things that a
user-centric communications client can and should address, and that if
we do it well, that kind of client would be quite successful. I'm
thinking not just of the "traditional" benefits of desktop clients, but
also of benefits like giving people access to multiple types of
communications from multiple "vendors", allowing for decentralized
choices around user experiences, allowing for locally hosted copies of
data under user control, etc. (I discuss some of them below)

> and 2) MoMo must remain committed to the individual user,

Yes to 2).

> therefore 3) Thunderbird does not make any sense as a flagship product
> for the future world that you see for MoMo.

3) certainly doesn't follow given that i don't believe 1).

> That's what makes it really hard to make comments on directions for
> Thunderbird, as it does not really fit into the strategic future of
> MoMo - your product is RainDrop.

Raindrop is an interesting experiment in a bunch of things, but I see it
as fairly irrelevant to this conversation. I'm not sure how you got to
such a strong belief in my beliefs =).

> It seems to me that MoMo needs to either clearly articulate the
> technical direction that Thunderbird could take to morph it into a
> product that matches your strategic vision - or else agree that the
> individual user is not the ultimate target of Thunderbird, and let it
> develop into a product focused on various organizational or
> professional market segments. My fear is that you will hold on to
> Thunderbird as an individual email client for too long, and in the
> process allow any possible strength it might have had as an
> organizational product (or working professional-focused product) to be
> regressed into oblivion.

I agree that we need to paint a picture of a future version of
Thuderbird that is compelling, and includes not just technical direction
but UX vision, participation model, revenue model, etc. However, I
don't think that's something that can be done either a) with words
alone, or b) in isolation. Which is why I mentioned that we'll be doing
add-ons to explore ideas, and elicit feedback.

As an example, I'm really interested in Mike Hanson's add-on exploring
"people in the browser"
(http://mozillalabs.com/blog/2010/03/contacts-in-the-browser/,
http://mozillalabs.com/blog/2010/04/contacts-in-the-browser-0-3-released/).
What I find interesting in particular is that my own thoughts about the
topic have evolved as the add-on has evolved, and as Mike has reacted to
shifting environmental conditions. I'm hoping we can do the same with
our ideas about future possibilities for Thunderbird.

As to whether there is "latent strength" for Thunderbird as an
enterprise-focused tool, I've tried to be explicit that:

- MoMo isn't the right organization to do that, for a variety of
reasons which I've mentioned
- if someone else is interested in taking that on somehow, I'm more
than happy to talk.

To me this is us looking at the issue of user-centric or
enterprise-centric futures for Thunderbird, and deciding quite
explicitly in which case we'll lead, and in which cases we'll get out of
the way.

> I personally am not pessimistic about the role of a standalone email
> client for the individual, but I think that there needs to be some
> major changes in focus, understanding what, exactly, a standalone
> client offers over a webmail client, and designing the product to
> optimize those advantages.

Agreed. Here are some of my thoughts:

0) Communications have intent, and we need to understand what those are,
and build our software accordingly. An email from twitter telling me
that someone's following me has a completely different intentional
structure than your email to this list. In general, we need to be much
more aware of the social and psychological context of a communication
than we are now.

1) as the user agent, a communications client can put the user's
interest ahead of the service provider's. In particular, the
communications client can embrace the multiplicity of relationships that
the user has with both service providers and other people. Thunderbird
does that fairly well with respect to email/news (and to some weak
degree rss), but there are a lot of other modes that people use today.

2) as a client-hosted program, a comm. client should in theory be
customizable more easily than a hosted webapp. To the extent that those
customizations can be _effective_, I think we have an interesting
strategic advantage. There are complexities there w.r.t. security, UX
integrity, economics, etc., but there is a lot of "asymmetric advantage"
potential there compared to most alternatives.

3) as a public-benefit organization, we should also think differently
about who controls what. I think if we are able to think about how to
build software that puts users in effective control of their digital
lives, we can win a competitive battle against software that needs the
users to give up some level of control for their success. We just need
to be very cognizant of the fact that control doesn't mean either "lots
of knobs" or "if you don't like it you can fork it", but instead think
about the spectrum of control points that different people can use.


--david

[Kent James]

I want to try to summarize what I am hearing from people, rather than
focus on a point-by-point commentary or rebuttal that would result in
the kind of pointless long-winded discussion that this list is supposed
to be preventing.

First, let me point out that the only agreed market segmentation is the
"individual" versus the "enterprise". Personally I don't think that is
enough granularity to help truly understand direction, but I'm not sure
continuing that discussion is worthwhile.

What has been emerging instead is a collection of advantages (which are
closely related to features) of a standalone client that Thunderbird
should embrace to be effective. (This is by the way classic "feature
focused versus market focused" product understanding that your marketing
consultant will counsel against.)

I understand fairly well:

1) Privacy ("A desktop client is essential for privacy of the individual
and private mail.")

2) Performance (speed and GUI comfort)

3) Customization ("a comm. client should in theory be customizable more
easily than a hosted webapp")

4) Source consolidation ('giving people access to multiple types of
communications from multiple "vendors" '). Clearly my EWS work is
targeted squarely here.

I understand less well:

5) "Communications have intent, and we need to understand what those
are" Although I think I understand the problem, I am not sure that
there are proposed features that address this, other then rough
categorization means such as tags, filters, and virtual folders.

6) "puts users in effective control of their digital lives". While I
think this is a fascinating philosophy, as we see the embrace of
Facebook and Apple products which are diametrically opposed to this,
there is very little acceptance of this as a value by the public.

I would add to this my own under-appreciated area:

7) Activity dashboard. At least for me, my standard task management
strategy revolves around a few simple organizing schemes that are done
in Thunderbird - favorite folders and starred messages. For most people,
they only have a few places that they go daily to figure out activities
that need followup, and the client should support that well,
consolidating multiple information sources into a coherent scheme of
required actions.

Finally, responding to "we need to paint a picture of a future version
of Thunderbird that is compelling ... I don't think that's something

that can be done either a) with words alone, or b) in isolation."

I don't see anywhere an attempt to describe "with words" a compelling
vision for Thunderbird. Instead of "with words alone" let's embrace
"with words at least". Maybe that is where I get strange ideas about
what people believe and their strategy. If I don't hear it in words,
then I have to make it up.

Kent James

[David Ascher]

gotta run, but quickly:

On 4/26/10 5:05 PM, Kent James wrote:
> I understand less well:
>
> 5) "Communications have intent, and we need to understand what those
> are" Although I think I understand the problem, I am not sure that
> there are proposed features that address this, other then rough
> categorization means such as tags, filters, and virtual folders.

There are no specific proposed features here. Although I see gloda's
connotent as a useful bit of technology that allows us to build
"intent-miners".

Semi-automatic mailing list filter-creation as in
http://shane.caraveo.com/?p=11 is relevant, but not really enough.

But I'm explicitly not talking about features yet.

>
> 6) "puts users in effective control of their digital lives". While I
> think this is a fascinating philosophy, as we see the embrace of
> Facebook and Apple products which are diametrically opposed to this,
> there is very little acceptance of this as a value by the public.

The public hasn't been given much of a choice, now has it? Also, I
think it's too simple to claim that Apple and Facebook just remove
control. For many people, Macs and iPhones are more understandable, and
hence give more control, even if it's not without some compromises.
Similarly for facebook, w.r.t. who one gets messages from.

> I would add to this my own under-appreciated area:
>
> 7) Activity dashboard. At least for me, my standard task management
> strategy revolves around a few simple organizing schemes that are done
> in Thunderbird - favorite folders and starred messages. For most
> people, they only have a few places that they go daily to figure out
> activities that need followup, and the client should support that
> well, consolidating multiple information sources into a coherent
> scheme of required actions.

Yes, and something i hope you do get to explore that further in an
add-on, and we can have dashboard competitions.

--david

[Ben Bucksch]

On 27.04.2010 02:05, Kent James wrote:
> I want to try to summarize what I am hearing from people, rather than
> focus on a point-by-point commentary or rebuttal that would result in
> the kind of pointless long-winded discussion that this list is
> supposed to be preventing.
>
> First, let me point out that the only agreed market segmentation is
> the "individual" versus the "enterprise". Personally I don't think
> that is enough granularity to help truly understand direction, but I'm
> not sure continuing that discussion is worthwhile.

My feeling of this is:
We are targetted at average users. Not the totally novice clueless "I
just want my mail !!!!" users, but our core target group are neither the
hard-core techies. Just the average Joe, mom and dad, with a reasonable
intelligence, basic understanding of computers and GUIs, from almost all
age groups.

There are many open-source MUAs which target the techies, mutt to
mention one. There are not many few open-source MUAs which target
average users, and in many cases, we're the only viable open-source
option. That said, the techies are important, because they are potential
contributors and more importantly give mind-share. Average Joes listen
to the techies when they recommend something. If the technies despise us
(a very good and quick way to achieve utter hatred by techies is to
encourage HTML mail, because it affects recipients), they will not cheer
for us. Their cheering is essential in the word-of-mouth for private
users and even for small and big company rollouts. So, this target group
is essential to keep. We currently have a good size of the techie users,
and that's good.

(Also, as said, some features like speed of IMAP folders with 10,000
messages, or hidden prefs, are good for both power users and enterprises.)

So, what results from that is: Make a client which is very intuitive to
use, with a clean, nice UI and powerful, discoverable universal features
which get out of the way when not needed, but can be trivially and
naturally found when needed and applied for multiple problems. Make it
powerful to grow to increasing user needs as people progress, up to the
power users. This is hard, but possible 90% of the time, you need to
find elegant, natural solutions, but that's what makes a client great.

(And, given the many requirements that a single client for 3000 users
(both novice and power users) needs to fulfill, that's often needed for
enterprise rollouts, too.)

This is what Thunderbird should be (and, with limitations, is): A client
enjoyable and useful for normal users, allowing them to communicate and
work with fun and speed/ease, with a nice, welcoming UI, and serving
users up to power users.

Ben

[Dan Mosedale]

On 4/24/10 2:39 AM, Archaeopteryx wrote:
> A few pain points with this.
>
> 1) IIRC, there was the policy of an at least six months upgrade window,
> so delay the message by a month.

In an ideal world, with more resources, we would. As it stands, we're
still keeping our eyes open, and if we found something sufficiently
awful, we'd figure out what to do about it.

> 2) Thunderbird 3.1 has not been released yet but is mentioned in the
> message. 3.0 isn't linked in the distributor notes, but 3.1 isn't and
> its pre-release status isn't mentioned the first time you talk about 3.1

Good points; we could indeed have done better here.

> 3) Please add a how-to page how to prevent the user interface changes
> for the distributors, they probably don't want to tell every user how to
> switch from Smart Folders to All Folders or how to see again the message
> count in a folder.

Happily, both of these changes are included both of those things in 3.1:
All Folders is the default again, and the folder columns pane is
mentioned in the migration assistant.

That said, we also plan to have a page on MDC for folks distributing
Thunderbird that will have pointers to important resources, including
hidden prefs that site-admins may wish to set.

Dan

[Pavel Cvrček]

Dne 28.4.2010 3:55, Dan Mosedale napsal(a):

>> 1) IIRC, there was the policy of an at least six months upgrade window,
>> so delay the message by a month.
> In an ideal world, with more resources, we would. As it stands, we're
> still keeping our eyes open, and if we found something sufficiently
> awful, we'd figure out what to do about it

So organizations and users don't have quarantee support of older
version. I don't think this is good. Please provide some document with
info about support of older versions.

Regards,

--
Pavel Cvrček <pcv...@mozilla.cz>
http://www.mozilla.cz/

[Dan Mosedale]

On 4/28/10 12:23 AM, Pavel Cvrček wrote:
> Dne 28.4.2010 3:55, Dan Mosedale napsal(a):
>>> 1) IIRC, there was the policy of an at least six months upgrade window,
>>> so delay the message by a month.
>> In an ideal world, with more resources, we would. As it stands, we're
>> still keeping our eyes open, and if we found something sufficiently
>> awful, we'd figure out what to do about it
> So organizations and users don't have quarantee support of older
> version. I don't think this is good. Please provide some document with
> info about support of older versions.

The message that started this thread
<http://groups.google.com/group/tb-planning/msg/cdca47b707f86e68> is
that info for 2.0.0.x, and the development plan linked to from that
message <https://wiki.mozilla.org/Thunderbird:Thunderbird_Post_3.1_Plan>
is that info for more recent versions.

To be more specific, our current hope is not to support Thunderbird
3.0.x for too long after we ship Thunderbird 3.1, but rather to upgrade
all of our 3.0.x users to 3.1.x fairly quickly, in large part because
the set of changes between 3.0 and 3.1 is relatively small.

That does, however, depend on a some externalities, such as 3.1.x user
feedback as well as how quickly add-on authors make their 3.0.x addons
compatible with 3.1.

Dan

[Ben Bucksch]

On 28.04.2010 20:55, Dan Mosedale wrote:
> To be more specific, our current hope is not to support Thunderbird
> 3.0.x for too long after we ship Thunderbird 3.1, but rather to
> upgrade all of our 3.0.x users to 3.1.x fairly quickly, in large part
> because the set of changes between 3.0 and 3.1 is relatively small.
>
> That does, however, depend on a some externalities, such as 3.1.x user
> feedback as well as how quickly add-on authors make their 3.0.x addons
> compatible with 3.1.

I don't think the lifetime of 3.0 is a problem, I don't think many
people will shed tears over 3.0.
There are big organizations which are using 2.0 and don't see themselves
deploying 3.x any time soon. There needs to be a plan for them. Leaving
them insecure is not a good plan.

I'd jump in with and help that, but my funding is running out.
Is *somebody* (Redhat?) still maintaining the underlying Gecko with
security fixes?
If not, would it be crazy to try to port TB 2.0 app code to Gecko 1.9.3?
Well, yeah, of course it would. I mean: would it be feasible?

Ben

[Leni]

On 29/04/2010 4:55 AM, Dan Mosedale wrote:
> That does, however, depend on a some externalities, such as ...

> how quickly add-on authors make their 3.0.x addons
> compatible with 3.1.

In that vein, I would find it useful to know when:
https://addons.mozilla.org/en-US/firefox/pages/appversions
is updated with the next release.

Currently, addon authors have to poll that page. Some sort of
notification scheme (rss, email, twitter, whatever) might shave weeks
off the time that addon authors know that they can alter their
install.rdf for AMO.

Leni.

[Dan Mosedale]

On 4/28/10 12:05 PM, Ben Bucksch wrote:
> There are big organizations which are using 2.0 and don't see
> themselves deploying 3.x any time soon. There needs to be a plan for
> them. Leaving them insecure is not a good plan.

Our hope is that most organizations will be willing to make the jump to
3.1. That said, as with any transition, there are undoubtedly some that
won't.

The current plan is to create a tb-enterprise mailing list this week so
that folks interested in deploying in this space have a place to discuss
a variety of issues related to larger deployments, and this would be
very much on-topic.

> I'd jump in with and help that, but my funding is running out.
> Is *somebody* (Redhat?) still maintaining the underlying Gecko with
> security fixes?

I'm not sure; I suspect that if anyone is, dveditz who would know who.

> If not, would it be crazy to try to port TB 2.0 app code to Gecko
> 1.9.3? Well, yeah, of course it would. I mean: would it be feasible?

I don't know. If it did work, it would have the advantage of being
significantly more secure than a Tb2.0 running on Gecko 1.8.1.

Dan

[Dan Mosedale]

On 4/28/10 12:49 PM, Leni wrote:
> On 29/04/2010 4:55 AM, Dan Mosedale wrote:
>> That does, however, depend on a some externalities, such as ...
> > how quickly add-on authors make their 3.0.x addons
>> compatible with 3.1.
>
> In that vein, I would find it useful to know when:
> https://addons.mozilla.org/en-US/firefox/pages/appversions
> is updated with the next release.
>
> Currently, addon authors have to poll that page. Some sort of
> notification scheme (rss, email, twitter, whatever) might shave weeks
> off the time that addon authors know that they can alter their
> install.rdf for AMO.

I like that idea! Can I talk you into a filing a Bugzilla bug on AMO
for an RSS feed for that page and CCing me?

Thanks,
Dan

[Archaeopteryx]

That's https://bugzilla.mozilla.org/show_bug.cgi?id=408574 - I reopened
it as the solution was not practiable (subscribing to the Developer Hub
feed which contained many other items).

Archaeopteryx

[Leni]

Ok, I opened this:
https://bugzilla.mozilla.org/show_bug.cgi?id=562468

I leave it to wiser heads than mine to mark the one I opened as a
duplicate (if appropriate).

Leni.

[JoeS]

On 4/27/2010 9:30 AM, Ben Bucksch wrote:
> the techies are important, because they are potential contributors and more importantly give mind-share. Average Joes listen to the techies when they recommend something. If the technies despise us (a very good and quick way to achieve utter hatred by
> techies is to encourage HTML mail, because it affects recipients), they will not cheer for us.

Opps, sorry Ben, for sending that last to your personal email.

I feel obliged to reply to this, as I know it will not cause a "flame war" here.
100% of all corporate email that I receive is in plaintext & html I think this is a very common scenario given that most
corporate environments use Outlook or some other MS agent.
Replying "in kind" is very important for business contacts, especially if it contributes directly to the impression of a
prospective client.

This _is_ a user-centric need that has been ignored for a very long time, and I would argue that those techie types who
cling to the plaintext culture, are not much benefit to alleviating the problems in HTML composition and editing.

Just take a look at the "stale" condition of the HTML editor, as an example. (Certainly _does_ discourage HTML mail)
And I guess one could easily conclude, that this is purposeful
.
Thunderbird could be the leader here, since we can produce much cleaner, less bloated code than MS products which now
use msword to generate their HTML. (But try telling a TB user that pretty much everything you do in HTML compose requires
a work-around, or actually directly editing the HTML, and see how far that goes)

Personally, I think that if you send HTML, then you must understand some HTML, as well as CSS.
And of course you must always be aware of the recipients capabilities, as well as his expectations.

For many prospective TB user, learning HTML just to use TB to answer email "in kind", is not an option.

[Dan Mosedale]

On 4/27/2010 9:30 AM, Ben Bucksch wrote:
>> the techies are important, because they are potential contributors
>> and more importantly give mind-share. Average Joes listen to the
>> techies when they recommend something. If the technies despise us (a
>> very good and quick way to achieve utter hatred by techies is to
>> encourage HTML mail, because it affects recipients), they will
>> not cheer for us.

Interesting assertion. While this may have been true in 1995, why you
believe this to be true for the general case today, I have no idea. Do
you have specific data?

FWIW, I think most of what Joe says here is on target. Rich text is,
for most people, a better user experience, and the email world is
gradually moving in that direction, regardless of Thunderbird does.

Dan

[Ben Bucksch]

On 29.04.2010 02:01, Dan Mosedale wrote:
> On 4/27/2010 9:30 AM, Ben Bucksch wrote:
>>> Average Joes listen to the techies when they recommend something. If
>>> the technies despise us (a very good and quick way to achieve utter
>>> hatred by techies is to encourage HTML mail, because it affects
>>> recipients), they will not cheer for us.
> Interesting assertion. While this may have been true in 1995, why you
> believe this to be true for the general case today, I have no idea.
> Do you have specific data?

Yes. I have friends. And other tech people I talk to.

Their opinion hasn't changed much in the last 10 years - if anything I'm
surprised about their aggressiveness when it comes to this topic ("HTML
> /dev/null", calling Thunderbird names etc.).

Ben

[Ben Bucksch]

On 29.04.2010 01:31, JoeS wrote:
> On 4/27/2010 9:30 AM, Ben Bucksch wrote:
>> If the technies despise us (a very good and quick way to achieve
>> utter hatred by techies is to encourage HTML mail, because it affects

>> recipients), they will not cheer for us. Their cheering is essential
>> in the word-of-mouth for private users and even for
>> small and big company rollouts. So, this target group is essential to
>> keep.
>

> I feel obliged to reply to this, as I know it will not cause a "flame
> war" here.

"Plain text vs. HTML" is a classic flame war topic. Please leave that
sleeping dog lie, it's one of the most aggressive dogs that exist in the
mail/news scene. My side note was a faint hint to point out exactly
that. We have a very good compromise that most parties can live with:
You can create HTML mail (with bugs, see below), but we would in no case
default to it *, and we'll warn about the implications.

I do agree that the HTML editor has many bugs which are simply stupid
and unnecessary. Peter Lairo is tireless in pointing two of them out, my
pet bug is when I edit quotes crossing several quote levels, it annoys
me to no ends, every day. These can and should be fixed, and the
SeaMonkey guys told me some guy who forked the HTML editor code years
ago would be happy to not only merge his changes back to us but also
take over the HTML editor and continue to fix bugs. I'd be happy about
that.


Generally, please consider one thing, though: Once we have to fight
against Outlook sending MSIE-flavor HTML, and people demanding that it
works (with the same "business, works there, you have to" arguments that
you used), we have a serious problem. And not just us. That's why,
strategically, HTML mail is best avoided and discouraged.
(I'll cut out all the other reasons, to avoid said flamewar.)

> Personally, I think that if you send HTML, then you must understand
> some HTML, as well as CSS.

Well, that's not realistic, though. And that's the problem.

Ben

[Robert Kaiser]

Ben Bucksch schrieb:

> SeaMonkey guys told me some guy who forked the HTML editor code years
> ago would be happy to not only merge his changes back to us but also
> take over the HTML editor and continue to fix bugs. I'd be happy about
> that.

I'll break my radio silence on this mailing list (which I still dislike)
for one single comment on this:

That guy feels that the Thunderbird community doesn't want the
standalone HTML editor (KompoZer) to live in comm-central, so he is not
too enthusiastic about helping out a lot right now - but the plans as
such still stands and we are (more slowly than expected) working with him.

Robert Kaiser

[Ben Bucksch]

On 29.04.2010 14:15, Robert Kaiser wrote:
> Ben Bucksch schrieb:
>> SeaMonkey guys told me some guy who forked the HTML editor code years
>> ago would be happy to not only merge his changes back to us but also
>> take over the HTML editor and continue to fix bugs. I'd be happy about
>> that.

> That guy feels that the Thunderbird community doesn't want the
> standalone HTML editor (KompoZer) to live in comm-central

I'd love to have him here, though! We desperately need a maintainer for
the HTML editor. There are tons of bugs lingering since years, and
nobody there to fix them. And from what I heard, he did good work.

He releases his stuff under MPL tri-license, and gives credit openly to
mozilla <http://www.kompozer.net/features.php>. His name seems to be
Fabien Cazenave (aka Kazé <http://kazhack.org/>), FWIW.

Is that guy correct that TB people don't want him? If not, could we
please give him a different impression/feeling, that he'd be welcome,
and get the ball rolling? If he's right, what's the reason?

> [SeaMonkey] are ... working with him.

Great!

Ben

[Dan Mosedale]

On 4/29/10 3:33 PM, Ben Bucksch wrote:
> Is that guy correct that TB people don't want him? If not, could we
> please give him a different impression/feeling, that he'd be welcome,
> and get the ball rolling? If he's right, what's the reason?

I think the Tb people aren't yet sure what we want, and I think that's
what we've communicated with him, but it's conceivable he came away with
a different impression of our discussions.

To clarify, we believe that having a good mail composition environment
for both plain text and HTML mail is indeed an important long-term
goal. We're not at all convinced, however, that continuing to iterate
on the existing XUL-based compose window is a reasonable strategy to get
us to that goal. Furthermore, adding yet another standalone project
Kompozer to comm-central entrains two other significant issues:
governance (Kompozer isn't an official Mozilla project), and
coordination costs (tension between Tb and Sm around branching related
things is already non-trivial; adding more projects makes that problem
worse).

Until we make the time to lay down our composition strategy (which isn't
likely to be immediate), sorting through the other issues doesn't make a
lot of sense.

Dan

[Dan Mosedale]

On 4/29/10 3:57 PM, Ben Bucksch wrote:

> On 30.04.2010 00:51, Dan Mosedale wrote:
>> On 4/29/10 3:33 PM, Ben Bucksch wrote:
>>> Is that guy correct that TB people don't want him? If not, could we
>>> please give him a different impression/feeling, that he'd be
>>> welcome, and get the ball rolling? If he's right, what's the reason?
>> I think the Tb people aren't yet sure what we want, and I think
>> that's what we've communicated with him, but it's conceivable he came
>> away with a different impression of our discussions.
>>
>> To clarify, we believe that having a good mail composition
>> environment for both plain text and HTML mail is indeed an important
>> long-term goal. We're not at all convinced, however, that continuing
>> to iterate on the existing XUL-based compose window is a reasonable
>> strategy to get us to that goal. Furthermore, adding yet another
>> standalone project Kompozer to comm-central entrains two other
>> significant issues: governance (Kompozer isn't an official Mozilla
>> project), and coordination costs (tension between Tb and Sm around
>> branching related things is already non-trivial; adding more projects
>> makes that problem worse).
>>
>> Until we make the time to lay down our composition strategy (which
>> isn't likely to be immediate), sorting through the other issues
>> doesn't make a lot of sense.
>

> OK, I would take home as "not too enthusiastic" as well.
>
> If you don't want the resources or plan, and there's somebody willing
> to take the job, then why not let him? That's what open-source is about.
>
Because of the aforementioned governance and coordination issues that
need to be worked through. In the abstract, I think they are worth
working through. But I wouldn't prioritize that work above the things
currently on the plates of existing project leadership.

You're quite right that there is risk with not moving forward on this
quickly, and I currently believe that it's the right risk to take.

[Ben Bucksch]

On 30.04.2010 00:51, Dan Mosedale wrote:

> On 4/29/10 3:33 PM, Ben Bucksch wrote:
>> Is that guy correct that TB people don't want him? If not, could we
>> please give him a different impression/feeling, that he'd be welcome,
>> and get the ball rolling? If he's right, what's the reason?
> I think the Tb people aren't yet sure what we want, and I think that's
> what we've communicated with him, but it's conceivable he came away
> with a different impression of our discussions.
>
> To clarify, we believe that having a good mail composition environment
> for both plain text and HTML mail is indeed an important long-term
> goal. We're not at all convinced, however, that continuing to iterate
> on the existing XUL-based compose window is a reasonable strategy to
> get us to that goal. Furthermore, adding yet another standalone
> project Kompozer to comm-central entrains two other significant
> issues: governance (Kompozer isn't an official Mozilla project), and
> coordination costs (tension between Tb and Sm around branching related
> things is already non-trivial; adding more projects makes that problem
> worse).
>
> Until we make the time to lay down our composition strategy (which
> isn't likely to be immediate), sorting through the other issues
> doesn't make a lot of sense.

OK, I would take home as "not too enthusiastic" as well.

If you don't want the resources or plan, and there's somebody willing to
take the job, then why not let him? That's what open-source is about.

If you end up, later (you say yourself it's not likely to be soon),
deciding that you want to go another route and rewrite the editor, fine,
you can do that still.

At least we'd have some much-needed improvements in the meantime. And
you'd have another, realistic option at your disposal, while right now
the option is only theoretical (and who knows whether he's still willing
when you are...).

In open source, when there's somebody competent and willing, that's
great! Open source projects are driven by the contributors...

Ben

[Dan Mosedale]

On 4/26/10 5:05 PM, Kent James wrote:

> I want to try to summarize what I am hearing from people, rather than
> focus on a point-by-point commentary or rebuttal that would result in
> the kind of pointless long-winded discussion that this list is
> supposed to be preventing.
>
> First, let me point out that the only agreed market segmentation is
> the "individual" versus the "enterprise". Personally I don't think
> that is enough granularity to help truly understand direction, but I'm
> not sure continuing that discussion is worthwhile.

I would tend to agree with this, FWIW.

> Finally, responding to "we need to paint a picture of a future version
> of Thunderbird that is compelling ... I don't think that's something
> that can be done either a) with words alone, or b) in isolation."
>
> I don't see anywhere an attempt to describe "with words" a compelling
> vision for Thunderbird. Instead of "with words alone" let's embrace
> "with words at least". Maybe that is where I get strange ideas about
> what people believe and their strategy. If I don't hear it in words,
> then I have to make it up.

I think you're right to push on this: the lack of anything useful here
makes things too amorphous as well as much harder for all of us to row
in the same (or even related) direction(s). I'll try and draw some sort
of charter up for what it is I think we're trying to do, probably in the
vein of past Firefox and Raindrop charters, though I won't be doing this
immediately.

Dan

[Robert Kaiser]

Dan Mosedale schrieb:

> Furthermore, adding yet another standalone project Kompozer to
> comm-central entrains two other significant issues: governance (Kompozer
> isn't an official Mozilla project), and coordination costs (tension
> between Tb and Sm around branching related things is already
> non-trivial; adding more projects makes that problem worse).

Until a few days ago, I had hoped we could have at least you, me and
Kazé sit down in Whistler and talk some of those things over - but as it
seems that I haven't been invited (and I have no clue if Kazé has been),
I guess that's up in the air now.

So far, so good, enough said.

Robert

[Dan Mosedale]

On Apr 29, 2010, at 5:20 PM, Robert Kaiser <Ka...@KaiRo.at> wrote:

> Until a few days ago, I had hoped we could have at least you, me and
> Kazé sit down in Whistler and talk some of those things over - but a
> s it seems that I haven't been invited (and I have no clue if Kazé h
> as been), I guess that's up in the air now.

If we end up needing to do a phone call instead, that sounds workable
to me.

Dan