Calendar Project at a critical juncture

0 views
Skip to first unread message

Philipp Kewisch

unread,
Feb 19, 2009, 10:47:34 AM2/19/09
to
The Calendar project, which for several years has been working on the
Lightning add-on to Thunderbird and the standalone Sunbird project, is
at a critical juncture. We feel it's important to communicate this to
our users and contributor community, as your input will determine how
the project continues.

Recently, several contributors who were working on the project full-
time have left the project or have shifted to free-time contributor
status due to other obligations. This means their contributions will
be limited to their spare time, which is quite sparse given a full-
time job and family. This is a significant change from recent years,
and if no new contributors come on board, it means that the rate of
change will decrease dramatically. Our releases will necessarily have
to become less frequent, and the amount of bug fixes and new features
per release will decrease.

As a result of this, we have to take stock, and figure out how we're
going to go forward.

First, as much as it pains us, we have decided to step back from
Sunbird maintenance. Our next release will include Sunbird, but
subsequent releases won't unless new contributors take on the work.
Trying to support both takes too much time, so we had to make a
painful prioritization decision.

Second, our next major goal is to have a version of Lightning that
will work well with Thunderbird 3. Lightning won't be built-in to
Thunderbird 3 for a variety of reasons (see this post [1] by David
Ascher for more on the topic), but we're still on track to have a
release that gives users of Thunderbird 2 & Lightning a migration
path. That version will be a significant upgrade from Lightning 0.9,
including notable performance and usability improvements.

There's a lot of work to do to reach our goals, and as a result we're
not yet planning much beyond that. This is where we need your input,
both in terms of direction-setting -- given limited resources, where
should we focus and why? and in terms of more directly useful help --
if you've been using Lightning for a while, and know a bit about
mozilla technologies (any of XUL, JavaScript, CSS), or want to help
test, write documentation, or do something else not listed here -- get
in touch!

This is really a tremendous opportunity for anyone who is interested
and willing to help make a difference here for the project and its
hundreds of thousands of users -- get involved!

I hope to hear more from you soon!

Philipp Kewisch (Calendar Project - lead developer)

[1] http://ascher.ca/blog/2009/02/18/lightning_update/

Matthew Monaco

unread,
Feb 19, 2009, 12:31:57 PM2/19/09
to
> First, as much as it pains us, we have decided to step back from
> Sunbird maintenance. Our next release will include Sunbird, but
> subsequent releases won't unless new contributors take on the work.
> Trying to support both takes too much time, so we had to make a
> painful prioritization decision.

I like this decision. I think the calendar is more useful coupled with the mail
client. In addition it just seems to me that it might be easier in the future
to take the lightning code and have it run by itself than force sunbird into an
extension (but then I have no experience with this).


> There's a lot of work to do to reach our goals, and as a result we're
> not yet planning much beyond that. This is where we need your input,
> both in terms of direction-setting -- given limited resources, where
> should we focus and why? and in terms of more directly useful help --

The thing I look most for in lightning is groupware abilities, CalDAV GroupDAV
etc. Lightning will obviously get more attention with more use and the biggest
niche I see that needs to be filled right now is an answer to MS's groupware. A
mail server, sufficient calendar/groupware server, and Thunderbird+Lightning can
do this.


> if you've been using Lightning for a while, and know a bit about
> mozilla technologies (any of XUL, JavaScript, CSS), or want to help
> test, write documentation, or do something else not listed here -- get
> in touch!

I recently tried my hand at modifying Lightning to give the option to display
tasks by on the calendar by duedate. I was surprised at how far I got to be
honest. However I hit a standstill when I couldn't find some of the code that
actually "draws" some of the stuff on the calendar. I'm sure the DOM inspector
would have helped me but I ran into version gridlock. The DOM inspector I
downloaded which said it'd work with my version would not. I tried hacking at
it a little but to no success. IN SHORT, I think that we've got to make sure
all of the tools required for Lightning development are compatible.

gNeandr

unread,
Feb 19, 2009, 1:00:16 PM2/19/09
to
[19.02.2009 18:31] »Matthew Monaco« wrote:
> IN SHORT, I think that we've got to make sure
> all of the tools required for Lightning development are compatible.
>
FMPOV the build system for LG tied to the 'general' TB build process
makes it very difficult to contribute.
LG as an >>extension<< should offer an easier process to build it .. as
it's for other extensions.
Maybe the team (?) could offer an additional way to generate the XPI as
long as no compilation is required.
I expect there are some -- or a lot of -- modifications and/or additions
possible going that way.
Günter

Simon Paquet

unread,
Feb 19, 2009, 1:23:44 PM2/19/09
to
gNeandr wrote:

>> IN SHORT, I think that we've got to make sure
>> all of the tools required for Lightning development are compatible.
>>
>FMPOV the build system for LG tied to the 'general' TB build process
>makes it very difficult to contribute.
>LG as an >>extension<< should offer an easier process to build it .. as
>it's for other extensions.
>Maybe the team (?) could offer an additional way to generate the XPI as
>long as no compilation is required.

There's really no "team" anymore.

But why don't you make it happen?

Simon Paquet
--
Thunderbird/Calendar Localisation (L10n) Coordinator
Thunderbird l10n blog: http://thunderbird-l10n.blogspot.com
Calendar website maintainer: http://www.mozilla.org/projects/calendar
Calendar developer blog: http://weblogs.mozillazine.org/calendar

Robert Kaiser

unread,
Feb 19, 2009, 2:34:49 PM2/19/09
to
gNeandr wrote:
> Maybe the team (?) could offer an additional way to generate the XPI as
> long as no compilation is required.

I actually think that compilation is required to build Lightning, so
providing such shortcuts is quite hard.

Robert Kaiser

gNeandr

unread,
Feb 19, 2009, 3:08:44 PM2/19/09
to
[19.02.2009 20:38] »David Ascher« wrote:
> I wonder if one possible scenario, at some time, would be to split the
> bits of calendar that are compiled (libical, etc.) into one add-on,
> and then have a separate chrome-only add-on. That might allow more
> agility.
>
> --david
Sounds very much about the approach I'm thinking about. Having a
'simple' process to generate the whole XPI, but NOT to necessarily have
to compile those certain parts. Any idea who can help for that?
Günter

Dan Mosedale

unread,
Feb 19, 2009, 3:16:11 PM2/19/09
to
On 2/19/09 9:31 AM, Matthew Monaco wrote:
> I recently tried my hand at modifying Lightning to give the option to display
> tasks by on the calendar by duedate. I was surprised at how far I got to be
> honest. However I hit a standstill when I couldn't find some of the code that
> actually "draws" some of the stuff on the calendar. I'm sure the DOM inspector
> would have helped me but I ran into version gridlock. The DOM inspector I
> downloaded which said it'd work with my version would not. I tried hacking at
> it a little but to no success. IN SHORT, I think that we've got to make sure
> all of the tools required for Lightning development are compatible.

You picked the wrong day to download. :-) The branch version numbering
of Thunderbird changed just before today's builds were spun, and the
DOMi install.rdf hasn't yet been updated. See
<https://bugzilla.mozilla.org/show_bug.cgi?id=467761#c1>.

Dan

Dan Mosedale

unread,
Feb 19, 2009, 3:18:29 PM2/19/09
to
On 2/19/09 12:16 PM, Dan Mosedale wrote:
> You picked the wrong day to download. :-) The branch version numbering
> of Thunderbird changed just before today's builds were spun, and the
> DOMi install.rdf hasn't yet been updated. See
> <https://bugzilla.mozilla.org/show_bug.cgi?id=467761#c1>.

Whoops, that bug is for the last time this problem happened, I think
there's going to be another one for the current issue. But it should be
fixed soon.

Dan


Marcel Berteler

unread,
Feb 19, 2009, 3:57:06 PM2/19/09
to
Philipp Kewisch wrote the following on 2009/02/19 17:47:
> Recently, several contributors who were working on the project full-
> time have left the project or have shifted to free-time contributor
> status due to other obligations. This means their contributions will
> be limited to their spare time, which is quite sparse given a full-
> time job and family. This is a significant change from recent years,
> and if no new contributors come on board, it means that the rate of
> change will decrease dramatically. Our releases will necessarily have
> to become less frequent, and the amount of bug fixes and new features
> per release will decrease.

Sorry to hear about the loss of dedicated resources. for those of you
that leave or have left: thanks for your work and I hope you will
continue to work on this great project in your spare time. All others
out there that do not yet contribute: Please start doing so and remember
that even the biggest ocean is made of drops of water.

>
> Second, our next major goal is to have a version of Lightning that
> will work well with Thunderbird 3. Lightning won't be built-in to
> Thunderbird 3 for a variety of reasons (see this post [1] by David
> Ascher for more on the topic), but we're still on track to have a
> release that gives users of Thunderbird 2 & Lightning a migration
> path. That version will be a significant upgrade from Lightning 0.9,
> including notable performance and usability improvements.
>

I think this is a great decision as I have stated before and welcome it
especially for the reasons of being able to release outside of the TB
release cycles.

> There's a lot of work to do to reach our goals, and as a result we're
> not yet planning much beyond that. This is where we need your input,
> both in terms of direction-setting -- given limited resources, where
> should we focus and why?

As a corporate user, interoperability and synchronization are the
biggest issues for me. If Calendar can communicate with most frequently
used other calendar tools out there and my fellow board members can
synch their MS phone than there is no reason anymore not to move to TB
and LN and finally get rid of our dependency on outlook.

I would opt for making sure the basics work 100% before adding other
features. Its better to have a program than can do 2 functions 100% than
5 functions 85%. With this I mean for example focus on making sure that
iTIP is working according to standards and ensuring it can cope with
non-standard requests from other widely used calendar tools before
adding any other feature.

As for additional calendar provider plugins / extensions, I think they
should eventually end up in the LN plugin as having extensions for
extensions is really confusing end users more than necessary. But I am
sure this is a debate on its own....

Keep up the good work.

Marcel

Archaeopteryx

unread,
Feb 19, 2009, 6:51:55 PM2/19/09
to
The Calendar developers should also evaluate their long term strategy
and policies, i.e.
- Calendar mainly implemented features for business clients in the last
releases and now with the bundle with Thunderbird (which has Exchange
support not on its road map), this can't fully work (furthermore this is
a drop of the usual "event viewer" like a student, see
https://wiki.mozilla.org/Calendar:Target_Users ),
- performance hits have hardly been managed in the past,
- develop road maps for parts of the application and drive the coding in
a line from start to end (features shouldn't look like "under
construction; but Thunderbird has also this problem),
- who develops the code should also document it, because this is the
most time efficient and writing the documentation lets people check if
everything works logically and provides a more and more complete
documentation, encouraging add-on developers (who could implemented the
MAPI this way).

What would be needed to keep Sunbird alive (except from an up2date
design concept)? Maybe also the people who are interested in a further
development of Sunbird can show here up.

Archaeopteryx

Thomas Stache

unread,
Feb 20, 2009, 4:45:11 AM2/20/09
to
On 19.02.2009 16:47, Philipp Kewisch wrote:
> Recently, several contributors who were working on the project full-
> time have left the project or have shifted to free-time contributor
> status due to other obligations. This means their contributions will
> be limited to their spare time, which is quite sparse given a full-
> time job and family. This is a significant change from recent years,
> and if no new contributors come on board, it means that the rate of
> change will decrease dramatically. Our releases will necessarily have
> to become less frequent, and the amount of bug fixes and new features
> per release will decrease.
>

This has to be read as SUN having stopped funding of developers for
calendar, I hope they relocated the people and did not "let them go"
entirely. My best wishes to Daniel, Berend, Christian, Ause and the
others...
What I did not quite get: why was the situation kept so low key, out of
sight of the "community".

Hope to learn more in the coming weeks,
Thomas

Daniel boelzle

unread,
Feb 20, 2009, 7:09:30 AM2/20/09
to dev-apps...@lists.mozilla.org
Simon Paquet wrote:
> gNeandr wrote:
>
>>> IN SHORT, I think that we've got to make sure
>>> all of the tools required for Lightning development are compatible.
>>>
>> FMPOV the build system for LG tied to the 'general' TB build process
>> makes it very difficult to contribute.
>> LG as an >>extension<< should offer an easier process to build it .. as
>> it's for other extensions.
>> Maybe the team (?) could offer an additional way to generate the XPI as
>> long as no compilation is required.
>
> There's really no "team" anymore.
Huh? I consider myself still being part of the calendar team if you
like, and I suspect the same holds true e.g. for Philipp, Stefan,
Martin, Berend, ...you?

thanks,
Daniel

Mark Banner

unread,
Feb 20, 2009, 10:02:07 AM2/20/09
to

Why not just grab a nightly xpi, unpack it into two directories, do some
work in one and install into TB, etc, then when it works, do a diff
between the directories?

That's slightly simplified, but should be good enough for starters.

Standard8

Daniel Boelzle

unread,
Feb 20, 2009, 10:26:17 AM2/20/09
to dev-apps...@lists.mozilla.org

Sounds like the approach I'd suggest for "quickstart hackers", too.
Maybe somebody already has scripting at hand for this?

Daniel

Simon Paquet

unread,
Feb 20, 2009, 10:52:05 AM2/20/09
to
Daniel boelzle wrote on 20. Feb 2009:

>>> Maybe the team (?) could offer an additional way to generate the
>>> XPI as long as no compilation is required.
>
>> There's really no "team" anymore.
>
> Huh?

I meant to say that there's no *dedicated* team anymore at our former
corporate sponsor.

Cya
Simon

Robert Kaiser

unread,
Feb 20, 2009, 11:51:09 AM2/20/09
to
Simon Paquet wrote:
> Daniel boelzle wrote on 20. Feb 2009:
>
>>>> Maybe the team (?) could offer an additional way to generate the XPI
>>>> as long as no compilation is required.
>>
>>> There's really no "team" anymore.
>>
>> Huh?
>
> I meant to say that there's no *dedicated* team anymore at our former
> corporate sponsor.

And it's noteworthy that there are successful project out there that
don't have a corporate sponsor and never had one and still are moving
along successfully with a community team. Sure, it's not always easy,
but it's doable. I very much hope the calendar project will continue to
work well as a community project, basically.

Robert Kaiser

Simon Paquet

unread,
Feb 21, 2009, 6:02:09 AM2/21/09
to
Thomas Stache wrote:

>> Recently, several contributors who were working on the project full-
>> time have left the project or have shifted to free-time contributor
>> status due to other obligations. This means their contributions will
>> be limited to their spare time, which is quite sparse given a full-
>> time job and family. This is a significant change from recent years,
>> and if no new contributors come on board, it means that the rate of
>> change will decrease dramatically. Our releases will necessarily have
>> to become less frequent, and the amount of bug fixes and new features
>> per release will decrease.
>
>This has to be read as SUN having stopped funding of developers for
>calendar

Yes.

>I hope they relocated the people and did not "let them go" entirely.

They all still work there. Nobody lost their job AFAIK.

>What I did not quite get: why was the situation kept so low key,
>out of sight of the "community".

Corporate politics.

Simon Paquet

Bruno Browning

unread,
Feb 21, 2009, 11:26:11 AM2/21/09
to Robert Kaiser, dev-apps...@lists.mozilla.org
Robert Kaiser wrote:

> And it's noteworthy that there are successful project out there that
> don't have a corporate sponsor and never had one and still are moving
> along successfully with a community team. Sure, it's not always easy,
> but it's doable. I very much hope the calendar project will continue to
> work well as a community project, basically.

I agree completely. This is one reason that I'm happy to see the
meetings moving to IRC. The conference calls have been useful for
coordinating production of code by people working full-time on the
project, but they have been I think less useful for creation of
community. We should also consider posting meeting logs to the wiki so
that even people who can't be online at the time of the meeting can see
what happened and have a chance to participate in decision-making.
bb


Robert Kaiser

unread,
Feb 22, 2009, 10:40:30 AM2/22/09
to

If you're doing status meeting wiki pages like Firefox, Thunderbird or
SeaMonkey do, make sure to contact bsmedberg to also set up his script
to make those be auto-posted to planet as well.

Robert Kaiser

Reply all
Reply to author
Forward
0 new messages