We actually really like Zen Cart. It’s fast, clear, and customizable. From a quick look at the Magento demo and feature list, it looks like they’re starting with Ajax in mind, but it doesn’t look like there’s that much different in the administration area. Will have to keep an eye on this one.

We’ve been on the receiving end of this type of call quite a bit these days. The unfortunate part about the whole deal is that pricing often seems entirely arbitrary.

When I got the bills for surgery on my ruptured Achilles tendon, I was amazed by the difference between the original price and the final price negotiated by my insurance company. Even though I had a very high deductible and had to pay most of the bill before the insurance kicked in, just having insurance lowered the cost dramatically, in some cases more than 50%.

As a service provider with payroll, taxes, and overhead, however, I’m less inclined to negotiate. With open source products, we’re providing incredible value to our business customers. But if we don’t get fairly compensated for our services, we wouldn’t be around to help businesses negotiate the open source bazaar for very long…

Fortunately, last fall a group of developers forked the SQL Ledger codebase, starting LedgerSMB. LedgerSMB has the open source spirit of cooperation, open exchange of information, and a sense of excitement that’s been lacking in SQL Ledger. We’ve hopped on board LedgerSMB, and have switched our clients.

With the license change, we now see LedgerSMB as the only game in town–SQL Ledger just removed themselves from the competition. If you’re still using SQL Ledger, I encourage you to take a look at Ledger SMB. Read more about it here:
When GPL software goes bad | Realm of the Purple Dropbear.

Disclosure: We are contributing to LedgerSMB directly. We also paid for multiple years of SQL Ledger.

Using GnuCash to balance your checkbook is perfectly legitimate. It’s easy and it’s accurate. You don’t need a commercial product to do the same thing. GnuCash 2.0, however, can take you well beyond a simple checkbook: you can track your credit cards, savings accounts, and investment accounts, or you can keep a full set of books for a small business.

Linux.com | Using GnuCash 2.0 to balance your checkbook

This frightens most business people. In the business world, attorneys have designed all sorts of non-compete clauses they attach to contracts, to prevent employees from starting other businesses with the knowledge they’ve gained from working for you. In the open source world, anybody is explicitly allowed to take that knowledge embodied in your software project and set up their own shop.

How do you build a business around something you can’t control?

SQL Ledger/LedgerSMB
In the past couple weeks, there was a fork in the main open source financial project out there, SQL-Ledger. The users’ mailing list is full of insults and accusations between supporters of the old project and the people who’ve left to set up shop. It’s quite an ugly place to visit right now…

What gives the upstarts the gall to leave the project and start their own, LedgerSMB? How is this good for users? Why would they do such a thing?

Turns out, a whole bunch of reasons.

First of all, SQL-Ledger has always been tightly controlled by a single developer. While he accepts help from translaters, most other code he does alone. So new features take months to come out. I’ve been using the system for three years, and there still isn’t a payroll module. While there have been developers willing to help on the project, at least from an outside view the developer has not been that receptive to contributions from the community.

Secondly, while the code is free, the documentation is not. The maintainer of SQL-Ledger hordes knowledge about how to use it, and disseminates it only to people who buy the manual from him. While he has every right to do so–open source is, after all, a voluntary gift to the community when you own the code–it does seem to go against the open source ethos. It feels like a disengenious use of open source–hook them with free software but then force them to buy the manual to be able to use it effectively. Few other open source projects get away with this model.

Thirdly, the mailing lists, which are the main free support for the project seems to have been heavily moderated, and not in a fair or balanced way. I’ve had several of my posts that point out apparent bugs not make it to the list, along with a few answers to other people that might’ve helped them solve their problem but might have been considered too close to the secret sauce in the manual. Meanwhile, some vitriolic subscribers spew ugly insults to others on the list, with apparently free reign, as long as it’s in support of the lead developer. It’s not a friendly place to be, on the Internet, and probably does a lot to drive people away from what is really a great piece of software.

But it appears that the final straw was the lead developer’s complete disregard for a major security vulnerability. At least one developer found this hole nearly a year ago and informed the developer. While we’ve seen more than half a dozen releases since then, this hole wasn’t fixed during that time, until another developer stumbled on it. This developer also tried to work with the main developer to get the hole fixed, but was met with hostility and an unwillingness to take the problem seriously.
So the other developers felt like they had no choice but to take the code and start a new project that took these security concerns seriously.

As a result, all sorts of new possibilities become available: a whole new list of features people have wanted to see may get implemented; people can contribute directly to the project to see enhancements they need; a true open source feel, where people are actually helpful instead of just telling you to purchase the manual; and a sense of shared ownership of the code, not held hostage to a single developer who could decide to pack up his toys and go home.

Now, I don’t mean do speak ill of the original developer. SQL Ledger is really a great program, and he’s done a lot to make it that way. I’ve paid for the manual twice, most recently just to give him financial support to keep working on the software, not because I really needed it. But I do think SQL Ledger has outgrown what can be managed by a single developer, and he stands in the way of its growth. So I look forward to seeing a community-forked version thrive.

Mambo/Joomla 

SQL Ledger is far from the first business open source project to fork. Joomla recently celebrated its first birthday. Joomla is the result of the core Mambo development team getting into conflict with the company that sponsored it, and owned the Mambo trademark. So they all left the project and started Joomla. It took several months for the dust to settle, but Joomla is the clear winner of this fork, with some 2.5 million downloads already and some major innovations on the horizon. Mambo, while it still exists, has barely been able to keep up with security vulnerabilities, and has already lost some of the replacements brought in after the Joomla revolt, for apparently similar reasons.

SugarCRM/VTiger

Not all forks eclipse the original project. SugarCRM has become one of the most successful companies that uses an open source project as its flagship product. And the product is very well done. And it has also been forked–into a community project called vTiger. The reasons for this split are less clear–it apparently has to do with a group of free-software proponents who didn’t really like the idea of a clearly commercial open source project.

SugarCRM is released under a different license than Mambo or SQL Ledger (Sugar Public License, instead of the GPL), so the viability of vTiger is less clear. vTiger has diverged quite a bit from SugarCRM already, adding more enterprise management features like accounting and inventory management while SugarCRM has focused more on enhancing the customer contact side of things with workflow, email campaigns, projects and cases and the like. At Freelock, we’ve stayed on the SugarCRM side of this split so far.

Asterisk/OpenPBX 

Here’s a fork that seems to have dropped off the map. Asterisk is the incredibly popular upstart free PBX (office phone) system that’s starting to decimate the lucrative telecom market. And OpenPBX is an Asterisk fork that doesn’t seem to be going anywhere. It has a stated goal of being more stable and better documented, and while it’s still alive, I don’t hear anybody really taking them seriously.

Mandriva Multi-Network Firewall

I’ve even tried to do my own fork of a project. Mandrake Linux for years had a great firewall distribution, called the MNF. As it got long in the tooth, a replacement MNF2 was developed, but it wasn’t released under the same terms as the original. Mandrake had become Mandriva at this point, and it saw MNF2 as a corporate product, not something they wanted to make freely available.

The source code, however, was still covered by the GPL license, which means anyone can take it and start their own version. So we could take the MNF code, rebrand it, and release it under a new name.

Unfortunately, I’ve got a few too many projects on my plate, and so that project didn’t get off the ground. Meanwhile, the formerly thriving community around the MNF has completely died–the mailing list which used to be very active hasn’t seen a post in months. This is a project that could still make for a very fine fork, but that takes time and effort, and nobody has stepped up to the plate to make it happen.

To fork or not to fork

Creating a successful software project of any kind is a daunting task. In the open source world, forks are a natural part of the development of projects. In a very Darwinian way, some forks succeed and grow to become thriving projects of their own, while others die a silent death. A few fill the niche of the parent project, killing it off completely. Forks can be very unsettling, especially when they happen to projects you rely upon for day to day business. It’s generally better to concentrate developer talent into fewer projects, making them develop faster and better. But in the long run, forks are sometimes unavoidable. Forks are an activity that make open source projects thrive, and ultimately result in better software for us all.

Solve the Payment Processing Problem [eCommerce]

“When people ask me what can the average person do to stop identity theft, I say, ‘nothing,’ ” said Bruce Schneier, the chief technology officer of Counterpane Internet Security. “This data is held by third parties and they have no impetus to fix it.”

We’ve written about Schneier before. He is the author of several books about security, and takes a very pragmatic approach. In a recent post on his blog, he talks about the lack of responsibility the data warehouses take for their information links.

We’re also starting to work with merchant account providers, and frankly, I’m quite appalled at the careless disregard the big processing services and credit card companies have towards credit card fraud.

Let’s separate credit card fraud from identity theft for this discussion. Identity theft involves stealing your identity and using it to commit crimes, get around immigration laws, or generally hide the true identity of somebody. While that’s a definite problem, especially if it’s your identity that’s been stolen, it’s a different problem than the more simple credit card theft and fraud.

For any given credit card transaction, there are three groups of people involved:

1. The consumer, who uses a credit card to make a purchase
2. All of the middlemen who facilitate the process of moving money from the consumer’s account to the merchant’s account.
3. The merchant, who sells the goods and receives payment from their processing service, and

Now, everybody’s talking about the risk to the consumer of doing online purchases, and all of these recent information leaks are scaring people from using or having credit cards. But consumers really don’t have any risk here at all, thanks to Senator Proxmire thirty years ago–if you use a credit card, you’re not liable for more than $50 of any fraudulent activity on your account. We have strong protection for consumers, and this protection is completely effective today for consumers faced with credit card fraud.

In the current situation, the financial industry isn’t affected much, either. When a consumer complains about fraudulent activity on their credit card, the processing service simply takes the money back from the merchant account at the other end of the particular transaction. On top of that, they charge the merchant a fee for processing the transaction reversal. And they probably charged the merchant a higher rate for the original charge, if there was anything fishy about the transaction. Furthermore, the more fraud that happens with a particular class of credit cards, the more justification the processing services have for charging a higher rate to cover the “costs” of the fraud.

In other words, each incident of credit card fraud actually generates additional revenue for the processing services!

Who pays? The merchant. Merchants sign up for credit card processing services because in most cases, businesses that start accepting credit cards typically see a ten to twenty percent increase in sales. But this additional sales comes with costs. There’s a monthly fee for the service. You have to buy or lease the card swiping boxes. Each transaction costs 18 to 30 cents, depending on the plan. And then the account provider deducts anywhere from 1.8% to nearly 4% out of the total sales price as a commission.

Think you’re getting a good deal on a processing service? Better look closer at that monthly statement. Quite often any advertised low processing rates a bank used to sell their service are added to cryptic fees and other sleazy ways they pad the bill so that their cut becomes bigger than it looks. It’s surprising they can get away with such blatently dishonest practices.

Charges on a merchant account statement are broken into “qualifying” and “non-qualifying” rates. Qualifying transactions get the lowest rate, while non-qualifying transactions often cost twice as much. All sorts of things can make any particular transaction non-qualifying: the card swipe isn’t read correctly so the merchant punches the number in manually; the consumer uses a business card at a merchant that is classified as more of a consumer account; the consumer adds more than 25% onto the bill as a tip.

And when these non-qualifying transactions turn out to be fraudulent, the entire transaction is reversed–the credit card processer withdraws the entire amount from the merchant’s checking account, and charges a handling fee. Much like what happens when a check bounces.

Credit cards are great for consumers, but becoming more and more of a risk for merchants. Unless something is done to place the responsibility for credit card fraud more squarely on the financial services industry, we’re likely to see more stores that no longer accept credit cards, the same way most have stopped accepting checks, for exactly the same reason.

Make sure you read the comments at the bottom of the page. At Freelock Computing, we’ve done half a dozen test deployments for various customers, and haven’t put any into production quite yet. We’ve found that if all you need is a basic shopping cart, it’s great. If you need something customized, it’s generally easier to start from scratch.

Right now, it reads customers, vendors, and services directly from SQL Ledger. In its next phase, it will transfer hours directly into SQL Ledger invoices!