Open Source Billing Solutions?

antis0c writes: "I am in the process of starting up an ISP, and I've been trying to find some really good Open Source Billing Software. I've looked around quite a bit, and the only truly Open Source solution I found was Freeside. It seems to offer a lot of what I need; Real-time credit card processing, MySQL database backend, Radius and Apache support, and all the general account management things you expect, but the user interface really leaves much to be desired. It doesn't feel very secure at all as it uses a lot of suid scripts and suEXEC in Apache and it also requires a lot of 3rd party Perl Modules (21 to be exact) which getting them all to work properly in conjunction with Freeside seems like a harder task than jumping through hoops of fire. My question is, what kinds of Billing Software have you guys used, and [what are] your good/bad experiences with it?"

Billing software and a lot of other infrastructural nitty-gritty is probably keeping a lot of businesses from switching to the joys of Open Source software for their backend. And if it requires 21 3rd-party modules to make Freeside work well, wouldn't some bright soul like to sell the work of neatly packaging those modules back to Freeside, so all will benefit from them? It would certainly make a nice diagram in the to-be-written textbook The Economics of Open Source Software.

I have an "Ask Slashdot" question, too

Is Slashdot now the formal replacement for Freshmeat?

http://freshmeat.net/search/?q=billing [freshmeat.net]

I anxiously await my answer.

-- Flavio

Re:Are you sure you could trust it ?

• You have obviously not paid attention to most EULA's.

You obviously have never paid more than $39.95 for a piece of software. Try buying a billing system for $100K. You don't get a CD ROM in an envelope with a EULA stuck on the outside. You get a CD-ROM and a multi-page contract, probably customized for you. Believe me, any such contract that released the vendor from reasonable liability would be laughed out of the corporate counsel's office.

• At least with open source software you "can" crack open the hood and look at it.

I agree 100%. You can also do that if you purchase a source license if the commercial software you buy offers one. Heck, if you're so 1337, you can always write it yourself. (Isn't this the point in the debate where someone claims that a billing system can be written in 10 lines of Perl?)

The issue is cost/benefit. If I get an open-source program, do I have an expectation that I'll spend my valuable time repairing it? If I buy a commercial offering, I may get screwed (many have), but I have an expectation that I won't. Believe it or not, most people who buy software find that it does what they need it to do (even people who buy it from Microsoft... imagine that!).

Apache, Linux, GNU emacs and other popular open source software are popular because they allow me to hack the code, but they don't require me to do so. If I install Debian, I have a reasonable expectation that it will work pretty well without me hacking the kernal. That makes it a very valuable piece of Open Source software. If I install NetFoo v.0.1, I may be in for more of an adventure. If NetFoo is critical to my financial success, I might want to buy the commercial offering.

• Well, going back to my first paragraph, most commercial software doesn't have a warranty that actually does any good.

Let's try to keep things in perspective. We're not talking about "Space Rampage, Network Edition" or any other boxed software you can find on the shelf at CompUSA. We're talking expensive, vertical-market billing software. Anything generalizations you have about "commercial software," no matter how true, probably don't apply.

Free billing software

...anybody else feels the irony in this?

Karma karma karma karma karmeleon: it comes and goes, it comes and goes.

Harder than it sounds.

It's got to be said, billing systems are Hard.

I used to work in Cellular billing systems, and I know the greif and sheer volume of changes that billing systems must go through in order to fit in with the rest of the enterprise.

Basically, the way I saw it, people had two choices

• Develop and use their own in-house systems, and take the pain that comes from having to have a full-time developement staff available
  
• Buy in a solution that fits 90% of your needs, and make do with the other 10% or change the way the company works to fit in with the software.
  

The basic problem being that "Billing" is better termed "Customer care and billing" software. It's got to not only handle the grunt work of creating invoices, tracking address changes, printing statements/invoices, but also do the "smart" stuff, e.g. create a picking note for the shipping guys when new customer signs up for special-offer-of-the-week. It's got to be easy to use for your staff, have extensive reporting for the higher ups etc etc.

My advice: get Freeside (or any other fine slashdot suggestions) and then work from there, but for gods sake, use a better database than MySQL. A few thousand invested in a good quality database backend machine and software solution with Veritas or similar backup solution will save tens of thousands of $LOCAL_CURRENCY_UNIT in hassle, downtime, etc etc.

PS: WRT to the "3rd party Perl Modules (21 to be exact)" that is exactly what the Bundle:: mechanism is for.

Our in-house solution.

I work for an once major ISP in the Northeast which was recently purchased by a large multinational. Here, we developed an internal solution, thanks to our in-house development department.

I should preface this by saying that I don't know if what I'm about to describe is patented. If not, it probably could be, and chances are the new parent company will patent it if they hear me. But have little fear; the parent company is not, by any reports, the sort that even knows about Slashdot.

Essentially the system runs out of Sybase (though could presumably run out of any other SQL db). The interface is a very nice (in terms of feature set) GUI which unfortunately is only for Windows (even though we are a Sun house; this is probably because its hard to find billing workers who are Unix savvy).

Anyway, the GUI is used to make any sort of changes to the account base. The data for any given account is arranged in multi-field windows, you can open individual services in an account to tweak them, search for an account by service name or account number, yadda yadda. The neat thing is that every time a change is made, a sequence of tasks (defined in the database for type of account and type of change) is initiated (by stored procedures), and these tasks connect to each of our production machines (as needed), which all run an internally developed server daemon. This daemon handles requests and parameters to run one or more Perl scripts (or whatever) which reside on those machines, to set up/modify/delete the service on the system.

The other beauty of having an internally developed billing system is that we were able to easily integrate this system with our Web site, and this has allowed us to provide instant online signup for certain services, as well as an online account manager for customers to tweak their accounts and services. And since the task system is a client-server model, you could easily adapt this for any server platform (in fact, I think we already have, for the NT hosting services we offer).

When the parent company was starting to figure out what they wanted to do with their new toy (i.e. us), they were going to go and buy a $30,000 billing system that I think ran in VB and didn't interface with anything (we would have probably ended up using both that and our internal system in the best case scenario). The development team (whose value was in question for some strange reason) then piped up and decided that a few suits needed an immersion course in our billing system. Needless to say they decided not to dump $30,000 into some hackneyed third pary solution.

Of course, most ISPs probably don't want to invest in a development department, but we were special in that we were founded by a computer programmer. For years (prior to the "merger") our company name was just a D/B/A for his tiny software company. He decided in '94 that the Internet was the future, and soon found himself running a rather successful independent regional ISP instead.

Re:Are you sure you could trust it ?

You have obviously not paid attention to most EULA's. They are usually very specific about releasing the company from liability. Couple that with UCITA and that spells disaster.

At least with open source software you "can" crack open the hood and look at it. So can others. And, no, most people do not go through the code line by line. And generally there are enough diverse developers and users on any major project that something like a back door would not go through.

You mentioned no Warranty. Well, going back to my first paragraph, most commercial software doesn't have a warranty that actually does any good.

Who contributes?

I've worked at two different companies that used linux for billing and IP accounting etc. Not a single one has ever contributed back to the codebase. They download the source, hack it to suit their needs and when they find a bug they bitch and moan until someone else fixes it. If they manage to fix it themselves they don't bother to generate a patch and contribute it. Is this the experience other people have had?

Excellent solution available (Akopia Interchange)

If you take a peek at Akopia [akopia.com], you will find a very robust, very well tested solution. They have changed their name since their initial product, as they merged with another company whose name escapes me.

I used their previous product and was extremely pleased, and when I relaunch our billing system in march, we will be using Akopia's system.

It has everything you are looking for, is open-source, AND has been tested by the masses over time.

What more could you want?

Those who are smart?

Sorry I don't have an answer to your question, but assuming users do this frequently, here's a question: are they only cheating themselves?

Sure, these companies get software for nothing, and can keep all the benefits of that initial version for themselves, but think about what happens as the software evolves: the cheaters spend money to get that extra feature or fix, then by keeping it to themselves, they have a choice to make every time the public version gets upgraded: keep their own version, integrate their code, or go with the clean, new version.

If they keep their own version, they have to forgo, integrate, or reimplement every feature the community invented. So they spent on their stuff, but either had to spend more to keep it, or end up with fewer features;

If they integrate their code, they have to spend money to get that integration, and they also face the same choice when the next upgrade comes along;

If they go with the clean version, they set aside the initial investment in their own features and fixes, and maybe they don't get the benefit of those features anymore.

But if they had not cheated, every patch of theirs that became part of the public version would still be available to them, with no additional cost, and they would get, for free, the benefit of the rest of the community's patches.

This is the inevitability of open source: not sharing information decreases its use value. It only is more valuable as a secret if you sell it, but then that value lasts only as long as no-one else out-thinks your secret.

Industry-wide Problem

What you describe is an industry-wide (the industry being business and accounting software) problem, and not in any way confined to open source software.

I develop business software for a living, and as a rule the state of business software technical development, security, and UI is abysmal. It's the reason why my business has grown 50% per year for 3 years -- there simply aren't good in-the-box solutions for most business operations problems.

Two examples: I did research for a temp agency, looking for temp placement software. Out of 20 packages my assistant reviewed, only 2 passed our "usability" test (some vendors threatened lawsuits if we published our reviews!) and those two each cost over $30,000 for 5 users. Second, one of my clients purchased a $150,000 legal billing system. They now pay me $25,000 per year for support and troubleshooting they can't get from the vendor, and are considering having me write them a custom program in 2003.

Further, because of programmer shortages and legacy compatibility issues, most proprietary solutions use out-of-date technology. Probably half of those bad Temp Placement apps were still using DOS/Btrieve.

The software situation for OS software is just as bad, in a different way. Fully debugging the UI, and writing the help files, are hard, boring work, and as a result seldom gets done unless some company pays a team of programmers to do it. Still, I'm pushing my clients towards OS because at least that way they're not dependant on the vendor to fix problems and write add-ons.

My advice for the ISP? Find an OS package with good architecture and technology, but bad UI, and pay some money to develop a good UI! Remember, "Free Software" means "Free Source" not "Free Beer," and you're expected to contribute out of your pockets to the development of OS software.

Josh Berkus, Aglio Database Solutions

Re:Open Source Shipping

Just a quick correction here. UPS and US Postal both have very cross platform API's that can access their servers across the net for shipping calculation. Both can be accessed with http calls from darn near any server side language.

It's only FedEx that requires you to run their software on only the platforms that they have decided to support. Worse yet, you pretty much need root rights in order to install the damn things, so forget about using their crap on a shared account.

UPS uses an http Get string sent along with the header to send in weight and zone info. You then get back a formatted html page that can be parsed. I personally used cURL being called from PHP to make this one happen. Best of all, once you've got everything tweaked in, you don't even have to identify that you're an authorized user to the server. It is a VERY sweet setup.

US Postal uses an XML exchange. Toss a formatted XML document, with your account info, weight, and zip codes, and you get back an XML document to parse all out. Again, cURL is a great way to make this exchange happen in the backend. Once the exchange occurs, I parsed this out with PHP and had all the info I needed. Their docs have Perl, VB, and Java examples too.

On top of all that, cURL will also run on an NT machine, as I got to helping a bud of mine implement this with ASP. I think he went and used some DLL file that did pretty much the same kind of thing, as it was easier to code for in ASP. Thing is, it was very doable.

Open Source? Billing?

Isn't this a paradox? Surely everything should be free? Open Source Billing Software sounds like Vegetarian Slaughterhouse to me.

Oxymoron

Sorry, but when I read Real time credit card processing in the same sentence as MySQL backend it gives me the jitters.

Now, before you folks unpack your baseball bats and woodoo dolls. This is not an attempt to degrade MySQL, but it's transaction processing capabilities are in beta at best, and I wouldn't consider it a proven enough platform to handle any financial transactions.

That doesn't discredit it's qualities as a proven backend for retrieval mostly databases which are not mission critical.

You may want to look into PostgreSQL for a transaction capable open source db.

duck & cover

Freeside Solutions

I'm not sure if the reader in question actually realised this, but SISD do offer commercial services. Yes, you have to pay for them. They include preconfigured machines, installation, customization and training. The webpage to said commercial services can be found here [sisd.com]. If freeside is ugly to you, ask them to customize it. If you cant get freeside to install, get them to. If you dont have to pay $$$ to buy the software, then there will be room in your budget for this, wouldnt there?

---

The good and the bad.

I've been running my own ISP now for about two years and tackled this same question at startup. I initially started off using a program called Optigold [digitalpoint.com] that was decent, though not OpenSource. The great thing about it was the amount of feedback that users could contribute to the development of the package, and updates came out for the package constantly. The software is also free to use until you have more than 100 customers, which is a very fair pricing scheme I thought. Optigold is, however, tied to Filemaker Pro [filemaker.com] which may be good or bad depending on your past experience. I had done database administration in the past using Filemaker, so at the time it was a good decision.

That said, I have since switched to just using Quickbooks Pro [quickbooks.com], for no other reason than it's very simple and straightforward. I can also charge credit cards right from the Quickbooks interface, which makes it very convenient. All the other packages I've tried (including Freeside and Rodopi [rodopi.com]) simply included too many features for my very simple needs, or required software I didn't want to run (Microsoft SQL server). I even started writing my own system in PHP, but abandoned the project because it simply wasn't worth my time. Anyhow that's my experience with the matter. As you mentioned needing Radius support, Quickbooks is probably too basic for your needs, as it's geared to generic services and not Internet Services billing, but Optigold [digitalpoint.com] may fit the bill. Good Luck.

Write your own... with some cautions

When the ISP I used to work for realized that Peachtree just wasn't going to cut the mustard for 30k+ customers, our development team spent about a year creating a Perl based helpdesk/dbm/accounting package that ran under Linux/Slorais and MySQL and had a web interface. The first version was rather neat, and worked pretty well, even when used by Level 1 support, the PHB's, and the MBA's in accounting and sales.

Unfortuneately, the second version was written by programmers *for* programmers. It didn't go over very well. I think they have refined it since...

comercial billing is where it's at

I'm actually serious about this. (and probably partial since i work for one of the largest billing providers in the world)
Comercial billing providers do everything for you, provide a nice front end, and can process exponentially more records in real time than you probably want to ever have to deal with. It's all about revenue assurance. If your open source billing solutin drops records or fails to send out bills, who do you go to? If your comercial software fails, you have a couple billion dollars behind it.
not meant to be flame bait, just meant to say that there are some really good comercial products out there for tier 2 & 3 providers (where a startup would fall) that come ready to install and are proven to work with tier 1 providers.

Re:I have an "Ask Slashdot" question, too

Freshmeat is great for listing software, but it does not evaluate its usefulness.

Furthermore, not all software is listed. For example, the link you gave does not list Zelerate [zelerate.org], an open source system that competes with commercial packages costing thousands of dollars.