MengdisconnectedCodeThis book demonstrates the long and painful development process of Chandler through the author's own experience.
Initially, Chandler was conceived as a personal information manager that contains emails, appointments, address books, tasks, and remarks. It supports multiple operating systems.
Chandler has no intention of challenging Microsoft's outlook and other software, but it should do just as well. This idea is already very challenging, but the real troubles have just begun.
Chandler is an open-source project developed by osaf. Unlike other commercial software, the development process of Chandler lacks powerful management and constraints, and almost no one is responsible for the entire project until more than a year after the project starts, the software development manager is available.
All members of the project should exert their creativity as much as possible, but the uncontrolled creation will only bring about unrealistic project requirements and unfeasible functions. Someone should have the power to cut down ideas that may lead the project astray in time. The Chandler project lacks such "constraints" on creativity, which is the root of all problems.
The no-constraint of Chandler is manifested in many aspects:
At first, Chandler was just a personal information manager, which integrated functions such as email, appointment, Address Book, task and remarks. Although such a demand has some challenges, some people have already done it, such as Microsoft Outlook, so it is still reliable.
However, the subsequent demands were a bit messy.
First, Chandler was intended for individuals and small business users, and later it was necessary to consider large institutions such as schools.
Chandler is also required to use P2P to synchronize data between different locations without relying on servers, but also to ensure the security of user data.
Chandler should be personal information management, but it should also be a scalable developer platform like Lego.
Chandler is an open-source project that needs to be built iteratively, but the interface and efficiency of the software must be very good.
All these requirements seem good, but they are self-contradictory and there are many technical difficulties.
Another example is that Chandler hopes to be able to build it using Lego blocks, that is, to make many standard parts and then simply assemble them. In fact, this is almost impossible.
Chandler also gave up using the Mozilla tool to build the interface, instead of using wxWidgets. The problem is that wxWidgets has many defects at that time ......
- Project Members think too much"
At first, everyone had to argue over what kind of database to use and what kind of backend, then the interface, and so on ......
In general, the many demands of the Chandler project are self-contradictory, and the technology used is somewhat advanced. The most important thing is that there is a lack of a strong management core to decide on many issues of the project.
We always hope that our project can be the best, but in fact, as long as each part is better, it is enough to make the entire project the best. If local optimization is required, the project cannot be completed.
Many times, some seemingly conservative practices are the best. For example, the Linux kernel is based on the traditional single-core architecture, although it is complex, but it works; and the FSF-first-funded Hurd is based on the micro-kernel architecture, theoretically it should be more advanced than Linux, however, debugging and development are extremely difficult. This is one of the main reasons why Linux is more popular than Hurd.
the best practice is not necessarily the best. The software development process is actually a compromise.