Back in January, we underwent a significant reorganization. Our founder Mitch Kapor stepped down from the project and provided enough funding to support paid staff for about a year. In August, we released 1.0 and since then we have seen a notable increase in our user base and continued growth in the user community.
As we head into the 4th quarter, we are now turning our attention to what needs to be done to ensure that Chandler remains a healthy, open source project that continues to serve the needs of its users as we transition from a paid staff to a volunteer-driven organization.
So, we felt it was time to back-up and take stock of what we’ve accomplished with the recent 1.0 release, and talk about our options, both in the short-term (next 3-6 months) as well as with respect to long-term goals.
The question before us is: Given our goals, what is the best use of remaining paid developer time?
Our mission remains developing high quality software to help individuals and small workgroups manage tasks and calendars.
We think this means delivering a solution that supports:
- A hosted service to support sharing and personal backup and syncing.
- A desktop application that is stable and performant with an extensible schema.
- The ability to get data in and out of Chandler (Desktop and Server / Service) in a variety of “standard” ways.
- The ability to work with other apps, where APIs and standards exist.
We also remain committed to remaining an open source project by:
- Continuing to grow and solidify the user community, including establishing processes to ensure that users have a voice in development efforts.
- Build a development community around a code base that is well-documented, fully testable, easy to maintain and and modular enough to allow for loose collaboration among developers.
Post 1.0 Priorities: Going forward, we’ve identified the following areas as key to the continued health of the project:
- Hub Service
- Support 1.0 users on both Chandler Hub and Chandler Desktop (We continue monthly releases of the desktop and are about to release Chandler Server 1.1.)
- Community (more posts on this soon!)
- Desktop Re-architecture Project
Desktop Re-architecture Project
As with any re-architecture effort, ours is a risky one, complicated by unknowns.
- Bug fixes and new feature work will slow down considerably. In the short-term we’ve decided to focus on strengthening Chandler’s “mobile device” support with extensions to Chandler Hub such as a new quick entry iPhone app and the ability to broadcast and receive email notifications. (However, we remain committed to fixing serious blocker bugs as well as helping volunteers interested in fixing bugs and building new features.)
- The timeframe for a fully re-architected, usable Chandler Desktop is still unknown.
Still, one thing that has been clear to us for some time is that the the performance and stability issues we face on the desktop can’t be fixed by continued work on the current code base.
Therefore, the choice we face is one of timing: Either we continue feature work on the current code base and defer the re-architecture to some later date (probably as a volunteer project), or bite the bullet and use remaining paid staff resources to work on re-architecture now.
In the end, we decided to re-architect now for a number of reasons, including:
- Re-architecture projects are unlikely to be implemented by volunteer developers.
- A re-architected desktop will be much friendlier to new developers and put Chandler in a stronger position for attracting volunteers, both for fixing bugs and building out new features.
That being said, our first milestone is to get something developers can start hacking on in the next 3 months, even if there isn’t enough UI for end-users to try it out.
The significance of 1.0: If we knew all along that we needed to re-architect the desktop, why did we decide put our energies into shipping a 1.0?
Shipping 1.0 has helped us clarify what the re-architecture needs to support. Both from a technical standpoint as well as from a design and user interface perspective.
Preview and 1.0 allowed us to put theory into practice. Through user feedback, we validated the problem space we had identified and workflows we had developed. We also identified what didn’t work and what wasn’t necessary. All of which will be essential in maintaining a sharp focus as we proceed with the re-architecture project.
Last but not least, 1.0 has been instrumental in helping us build a user base and enthusiasm for the project, two things we will need to sustain the project through the re-architecture effort..
Goals of the Re-architecture
- Address performance and stability issues.
- Make it easier for developers to fix bugs and add new features.
- Separate the storage, domain model, interaction and presentation layers of the app in order to parallelize development. (So for example, developers can work on building the interface for a new feature without having to wait for the domain model to be defined.)
- Comprehensive test coverage.
- Extensible schema.
– Allow developers to add functionality around an expanded range of data types supported by the app. (e.g. Documents, Media, Contacts and Directories, etc)
– Allow developers and users alike to define custom attributes.
Non-goal: Create a generic developer toolkit.
What we think we can accomplish in the next 3-5 months:
There are a number of paths we can pursue. At a minumum, we know we need to implement fully-tested interaction, domain and storage layers for Chandler. After that, there are a number of different ways to stage added functionality. A few configurations we’ve discussed include:
1) Sharing a simple task list through Chandler Hub. This would involve:
- Ability to import data from current desktop. (aka Port EIM.)
- Baseline sharing support.
- List view.
2) Basic Calendar
- Week view
- Detail view
- Recurrence
3) Initially bypass core Desktop 1.0 features and instead implement add-on apps (e.g. bookmarks manager, personal jogging tracker, reading list). Small, discrete apps that require less upfront investment in infrastructure work and allow us to get usable UI on the re-architecture branch faster.
For a more detailed discussion of our re-architecture plans, see Grant’s write-up on the Chandler-Dev list. Ultimately, our goal is build community interest around the re-architecture work. So please stay tuned for more discussions on the dev list and jump in with questions and feedback.
