If you've found PBooks, you've probably been searching for an open source accounting and bookkeeping project for awhile. There are a bunch of them out there - problem is, they either fizzled out after a short while, don't work very well, or suffer from egregious scope creep.
So why should you consider PBooks? What does PBooks have to offer that the other open source accounting projects don't have?
History
PBooks was started in 2003 and has been in active development and use for almost four years as of October 2007. Still, it is very simple and small. I try to spend an equal amount of time developing and testing the program.
License
I only recently released PBooks as an open source project because I like the way the Affero GPLv3 patches the "software as a service" loophole. That decision was a long time in the making, and I'm happy with the choice I made. I think the Free Software Foundation is doing a good job and I'm considering releasing more software under this new license.
Open Standards
Not only does PBooks use a great license, it also uses as many open standards as possible. If you check out the code, you'll see the great majority of the logic is in XML, XSL, and SQL. If you are like me, you are concerned about preserving your ability to choose. With PBooks and most of the software I develop, I don't like the idea of getting stuck with a bad decision and having to throw away a lot of hard work due to events beyond my control. I decided long ago that if PHP changed there license, or a better web scripting language came along, I wanted to make sure that the software I had written would not be worthless.
PHP Framework
The parts that require more specific functions are written in PHP, and that represents a very small portion of the application. The PBooks components are coordinated using Nexista, which is an LGPL licensed library which I didn't write but have been using for over four years and currently maintain. If nexista turns out to be a poor choice for reasons which I could not have foreseen, there are some great alternatives: Apache Cocoon (Java) and Popoon (PHP). These two frameworks are VERY similar to Nexista and PBooks could potentially be ported to running within one of those frameworks with a minimal amount of effort.
SQL
The database queries are written in standard SQL and are all stored in XML files to be used as prepared queries. One thing I might have done incorrectly was using MySQL auto-increments. Otherwise, all the SQL code should be completely portable from one RDBMS to another.
XSLT
Yeah, I know. XSLT is a lot of overheard. But guess what, its awesome. Right now, all PBooks XSL transformations are completed on the server, but with AJAX and a cool library like Sarissa, it would be feasible to perform XSL transformations on the client.
I've attempted to keep the PBooks XSL templates as standard as possible, refraining from temptation for niceties like registering PHP functions.
If and when something better than XSL comes along, it shouldn't be too hard to transform the PBooks templates into another format.
Accounting Structures and Logic
The accounting specific data was inspired by XBRL. XBRL is an open standard. In their words:
"XBRL is being developed by an international non-profit consortium of approximately 450 major companies, organisations and government agencies. It is an open standard, free of licence fees. It is already being put to practical use in a number of countries and implementations of XBRL are growing rapidly around the world."
Performance
With all these standards, transformations, and abstract layers, you'd expect PBooks to perform like a sloth. Well, no, its actually quite speedy. How did we get it to do that?
First off by keeping things simple.
Second, PBooks performs well by allowing the RDBMS to do what it does so well - manage relationships between data. Beyond that, for an accounting program, the work that a web application has to do is actually pretty minimal - basically providing a user-friendly interface to a complex and technical database.
Yes, XSL transformations can be demanding, but with the help of Nexista and PEAR's Cache_Lite, PBooks caches pages and expunges them on a regular basis making it unnecessary to perform the same processes over and over again.
Scope Creep Prevention Enforcement
Fighting scope creep is a tough thing to do. When you need to handle a new piece of information, its so tempting to add another column to a table. Instead, I've tried to take the time and think - what is this new piece of information, really? Is it something that everyone using this program will need? Is it something that every row of a database will need? Do the characteristics of this information change in different contexts?
What I've come up with is a concentrated data model that focuses solely on the management of financial data for the purposes of double entry bookkeeping. Everything is is just metadata that relates to it. Again, we have a situation where we need an abstraction layer between the PBooks data itself, and the metadata that describes in, but only the users really care about that. The database itself doesn't really care about what a customer's business name is, or whether an account has checks or not. And honestly, how much accounting data can a single user consume in a single sitting. I agree - not that much compared to how much there would be in total!
Therefore, PBooks has been purposefully optimized for managing basic bookkeeping data in its core, with a series of abstraction layers that will provide the flexibility to support a wide variety of purposes and use cases. The world of accounting and bookkeeping is interesting - there is a HUGE group of users who share a small amount of their requirements to an astonishingly degree, with the remainder being inversely proportionately diverse. That's what I have in mind while I'm developing PBooks, and I hope you agree that it was a good idea.
Young Project
Even though PBooks does have a fairly interesting history, its life as an open source project is still immature and unproven. There isn't really an active community, there is only one developer, and there is a lot of functionality missing. If you need an accounting and bookkeeping solution now, PBooks isn't right for you. If you are considering starting an open source accounting and bookkeeping project, I encourage you to consider joining the development of PBooks, or even forking it.
It's painful to see all the effort that has been put into prior open source accounting projects that can't be readily and easily leveraged, but its inspiring to realize that if they weren't open source at all, they would be entirely lost. Even though PBooks hasn't proven itself as a successful open source project, I hope that whatever comes of it in the future, it will be able to retain the value of the work invested in it thus far.