Goals and Objectives
This page lists the general objectives of all development for Publishers' Assistant software, regardless of implementation details. Not all of the goals listed here are attainable without some significant development efforts beyond the current implementation, but it's still important to list them here in order to know where we're headed.
Contents
Cross-platform compatibility
Publishers' Assistant software should be compatible with a variety of different computing platforms. This means that the program(s) will:
-
run on all major operating systems, including Microsoft Windows, Macintosh OS X, and GNU/Linux
-
be compatible with a variety of database backends, including Visual FoxPro/DBase, MySQL, PostrgesSQL, and SQLite
-
have multiple user interfaces, including a Web-based interface, a desktop interface, and a command-line or scripting interface
-
be extensible to less popular operating systems and databases with a minimum of effort
-
be accessible to all users, including those with handicaps and users who do not speak English
Note that it is not part of this goal that, for a given computing platform (OS, database, and user interface and language), Publishers' Assistant the company be able to provide technical support for the software. Obviously, we would like to provide support to as many users as possible (see below), but if users want to run the software on an unsupported platform, we want to make it possible for them to do so. This means (e.g.) providing an internationalization framework so that non-English speaking users can translate the software into their native language, even if we can't provide support in that language, and providing a database abstraction layer that allows interfacing with additional databases, even if we can't support them.
Maintainability
Publishers' Assistant software should be simple to maintain, from both a user and developer perspective. This means that users should be able to update their software without fear of harming their data; they shouldn't have to choose between bugfixes and new features on the one hand, and data integrity on the other. For developers, it means:
-
code is easy to read and understand, uses a consistent style, and adheres to a well-defined architecture
-
exceptions to the rules and concepts of the architecture should be rare, but simple to implement, document, and maintain when they do occur
-
code is versioned and can be rolled-back to earlier revisions when necessary
-
different parts of the software are coupled as loosely as possible, so that changing and maintaining one part need not affect other parts; in other words, developers can specialize and work on particular modules without being intimately familiar with the entire system
-
code is well-documented in both comments and in technical specifications, so that new developers can learn how to hack it easily
The way in which these goals are achieved may differ and evolve. Currently, for example, we keep code maintainable by using the same code and database in different products (notably, Publishers' Assistant and PAWeb). In the future, it could be possible to achieve maintainability while having different codebases for (e.g.) desktop accounting software and website software, as long as both sets of code meet these guidelines and there are developers actively maintaining them and ensuring that they work together.
Supportability and Community
In addition to being maintainable, it's important that we be able to provide technical support for Publishers' Assistant software for a majority of users. As mentioned above, we can't expect to provide commercial support to all users in all environments, but we should take care to develop the software in a way that allows us to support the majority of our users, in whatever environments and platforms they are using the most. Among other things, this probably requires that our main development environment(s) be the same as those of a majority of users.
In recognition that we can't support all users all the time, we should also provide ways for users to form communities to help support themselves. This means actively helping to build relationships between users and providing the infrastructure that will allow them to communicate about technical and non-technical topics. Wikis, mailing lists, blogs, and other online media are widely used for this purpose; we should continue to set these up for users and encourage users to participate in the community.
Independence
Publishers' Assistant software should be relatively independent of the technologies it relies on. In particular, this means that it:
-
should not require the use of proprietary software, or other software which we cannot modify and distribute ourselves if necessary
-
should have readily-interchangable frontends and backends
-
should not use programming languages or development environments tied to a particular platform