# PIM [*Personal Information Manager*](https://en.wikipedia.org/wiki/Personal_information_manager) BikeIM is not a [PIM](https://wiki.gnome.org/Apps/Evolution) and doesn't support calendar, todo lists, or user metadata. The unnecessary combination of PIM and a mail client is the reason this mail client is being released. In 2011, [KMail](https://www.kde.org/applications/internet/kmail/) chose to combine their excellent mail client with a broken PIM library that used MySQL embedded for a backend. Because it was unable to store >1GB of e-mail in the database, I couldn't use the latest version of KMail which caused me to write BikeIM. I don't know if KMail currently uses the same backend because I haven't been able to use it for years. I don't know if the backend has been fixed for the same reason. This is the reason that BikeIM will not attempt to store any information in a database, it is the reason BikeIM will never store more information about users than can elegantly be stored and used in a simple interface. It is the reason calendar, RSS, NNTP, todo, and so on will never be added to the main BikeIM program (though `contrib/` is still an option since users would not be harmed by code that never runs in the main program). While I insist that PIM is an anti-pattern for mail clients, this doesn't necessarily mean they are an anti-pattern for software, so BikeIM will be able to save documents that enable PIM so that other programs can handle them. Why use two programs instead of one? The UNIX philosophy is that a program should do one thing and do it well. A mail client should do mail. A PIM should do PIM and not e-mail. You can't do both and still abide UNIX philosophy. Many people are willing to sacrifice the UNIX philosophy for whatever benefit they gain from not having to click an second icon. BikeIM will not force that option on the user unless they opt in by running the contrib (which does not yet exist).