Hi,
In September, the LedgerSMB project will have its 10-year anniversary. A great milestone!
Not having been there at the time of the fork, I get the feeling that on the outset, the "vision" or "goal" of the project was to be the "more secure, more maintainable, more compliant, stabler" side of the fork.
While not all of the original goals have been entirely completed, huge steps have been made toward most of them:
- 1.2 fixed most SQL injection problems
- 1.3 introduced XSRF protection
- 1.3 separated large parts of the business logic from the HTML generation
- 1.3 introduced separation of duties
- 1.3 introduced enforcement of access control
- 1.3 introduced many, many data integrity controls
- 1.4 completed separation of duties
- 1.4 introduced a modern UI with HTML widgets
- 1.4 introduced a framework for efficient implementation of reports
- 1.4 completed the ability to attach documents in lots of places (started in 1.3)
- 1.5 makes the "modern UI" move complete
- 1.5 has loads of code cleanup at all levels
- 1.5 introduces "code quality" tests
- 1.5 introduces "browser based" tests
- etc.
With all these changes, LedgerSMB and SQL Ledger have an on-going divergence where the original goal probably isn't working too well any more. The question then becomes: if this vision doesn't work any more, then we'll have to come up with a new vision, a way to define ourselves.
Over the past years, I think we have used the following guiding principles:
- Build a technically sound basis
a. Separate business logic, storage logic and representation
b. Create a database model which supports much broader use-cases than the UI demands, simply because we can
c. Make sure we implement all the industry wide accepted -required- security measures for web-apps
- Be as open as we can be on each level:
a. Provide APIs on database, Perl and web(service) level, or try to move there
b. All development (and discussion) in the open, on GitHub, IRC
c. Using web-based services for easy contribution where possible (e.g. Transifex for translations)
d. Involve our users, e.g. discuss requirements (where possible) on the public mailing lists
Some of these come from the project's inception. Others, I believe come from the conviction that the world around us is (or has) quickly changing (changed) where not all functionalities can be built into the base application, meaning that integration on a multi-system level should be supported by the use of web services and exchange formats. In that world, LedgerSMB would/could take a central place handling PayPal/CreditCard payment confirmations, integrating with web shop and POS systems and others which don't have full ledgers of their own.
Hence the slogan on the LedgerSMB.org frontpage: "Foundation for your business" - which is also closely related to the "Statement of direction" (
http://ledgersmb.org/statement-direction-ledgersmb).
While the above does say something about the way we treat our users and how we solve our problems, it doesn't really define for whom LedgerSMB is trying to solve problems nor which exact problems we consider ours to solve and which ones we don't - or for whom we don't.
As Chris puts it <<We went from being 'everything to everybody' (SQL Ledger approach) to being 'anything to anybody'>> with the underlying assumption that it's better to have people customize their instance for their specific use-case ("mini-fork") than to try and fit all possible use-cases (workflows) into every screen.
For example, we've just recently seen a very active discussion on the users mailing list where a few different types of users can be recognized:
- Single person businesses doing their own accounting
- Accounting offices doing the accounting (once or twice a year) for small (typically single-person) businesses (in arrears, that is)
- Multi-person businesses who have their own accountant who is also in charge of payments and subject to peer-review requirements
These types of businesses come in various configurations:
- Sending (sales) invoices from LedgerSMB
- Sending (sales) invoices from other sources, later booking in LedgerSMB for VAT reporting
(and maybe others)
These groups seem to have different lenience for workflow inefficiencies, also based on different legal requirements depending on business size.
These are some of the things we're seeing with our users today. Other trends we're seeing, where I guess we should want to define our position as well:
* Digital data delivery requirements [ formats differ per jurisdiction ]
- Chambers of Commerce/Companies House
- Tax authorities
- Banks
* Digital invoicing requirements [ formats differ per jurisdiction ]
These requirements being put on businesses, raise questions for us to answer:
- As a "foundation for your business", should we be able to support these use-cases? And if we do, what building blocks do we need to put in place in order to be able to quickly develop jurisdiction-specific extensions?
- *Can* we support all of these use-cases (data delivery) given the fact that most governments require certification of the software? (And if the independent vendors want to file for certification, what does that mean for our project?)
And if we look further down the road, what more would you expect will become part of the sales/purchase workflows and accounting&reporting in the next 10 years? And how should the LedgerSMB project position itself in respect of these expectations?
--
Bye,
Erik.
Robust and Flexible. No vendor lock-in.