Slashdot Mirror
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.
http://freshmeat.net/search/?q=billing
I anxiously await my answer.
-- Flavio
They are NOT looking for a shopping cart. Btw, I just finished installing Interchange, what a PITA!!!
The guy is looking for software to run an ISP. Probably something that will add/delete users, bill them, and access their credit cards. To add delete users, it's going to need to tie into the user database, radius, mail and for domainhosting, httpd.conf.
More stuff would be great, but it's to early to think about that now.
Do not meddle in the affairs of sysadmins, for they are subtle, and quick to anger.
- You read the fscking code.
Yeah, that's the ticket. I'm sure everyone at Slashdot has read every line of code they've ever run. This guy is going through the rather time-consuming task of setting up an ISP. He has time to "read the fscking [how 'l337] code" when?Who read the "fscking" code to WU-FTPD, the FTP daemon that ships with many distros? Last summer, it got his by yet another buffer overflow attack. The source has been available how long? I'm sure you read it, Mr. 1337 H4X0R, so how come you didn't fix it right away?
- It's much easier to put a back door in proprietary code. Sheesh.
Sure it is, but proprietary code is backed by legal liability. Billing systems can cost anywhere from $50K to $1M. For that kind of money, I'm going to put in a back door? Sheesh.The real danger isn't deliberate back doors, it's accidental ones. Free software has NO WARANTEE. No one said it was going to work correctly, so too bad for you if it doesn't.
I know, I know, "read the fscking code." Yeah, that's practical. In fact, next time I buy I used car, I'll dismantle the engine and unpack the wheel bearings just to see if there are any problems. I'm sure that's what you do.
I'm not slamming Open Source, or even an Open Source billing system, but real people live in a world of risk, including the risk that the Open Source software they want to use might suck. Spending some money can be a reasonable way to mitigate that risk. I suppose that's hard to understand when your biggest risk in life is doing too many bong hits and missing The Powerpuff Girls.
- I'm sure the better way is to invest those $100K to improve NetFoo v.0.1.
That is a possible approach.That's the approach I'm taking with Jabber -- an open-source instant messaging system. My company needed to offer IM with gateways to the popular services. The commercial vendors of such systems are asking prices that would make you pee your pants from laughter. The solution? Jabber! The problem? The Jabber source base sucks donkeys!
Oh... I could go through the litany of Open Source Mistakes(tm) that the Jabber team has committed, but suffice to say that at version 1.2 (with 1.4 in prerelease), the code is worse than many 0.2 versions of other software I've used. Still, it's got a lot of good ideas and the crummy code base will pass -- particularly since I've hired someone to help fix it.
I've got some tight deadlines, but the bottom line was that paying someone to help patch up Jabber was more cost-effective than paying for someone else's proprietary code plus give me all the benefits of Open Source.
But this is a particular case. If I needed enterprise-ready IM today, I might be shelling out bucks for a commercial system. Open Source Jabber isn't ready for prime time yet.
Look, all I'm saying is that every approach has advantages, disadvantages, risks and rewards. You need to balance those (management types often do a SWOT [Strengths, Weaknesses, Opportunities, Threats] analysis). Anyone who insists that that Open Source is always the best way is just another fucking moronic idealogue. Yes, we've all had a bad experience with crappy software vendor who should be on trial in The Hague, but then you find someone or other with a clue.
Life goes on. If was easy, we wouldn't call it "code."
- 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....anybody else feels the irony in this?
Karma karma karma karma karmeleon: it comes and goes, it comes and goes.
My company rolled its own software. Although many principles would apply to many businesses, we wanted the flexibility of our own system. Don't get me wrong, and open source solution could be modified and flexed sure enough, but this was just the particular path we chose. The only reason we haven't opened the source for our system is because it is so custom that we doubt if others would find value in it. If you are running an ISP then you may find it a helpful experience to do your own system. Eventually you may be called upon to do it for a client, assuming you also do development.
-- Solaris Central - http://w
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
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.
perl -MCPAN -e shell
install Bundle::LWP
That alone takes care of MIME-Base64, Digest-MD5, URI, HTML-Parser, libnet, & libwww-perl. Next, do:
perl -MCPAN -e shell
install Bundle::DBI
That takes care of Data-Dumper, Data-ShowTable and DBI.
Harder than jumping through hoops of fire? Wow, I'd hate to see what he'd do if he had a task that was actually hard.
--
The unsig!
>> How could you be sure they had not put a back door in ?
Read the code? (Some people are idiots, I swear.)
-- Crutcher --
#include <disclaimer.h>
-- Crutcher --
#include <disclaimer.h>
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.
Terrorists can attack freedom, but only Congress can destroy it.
I work at a small ISP, and our entire billing application was created In-House. I created a 35 table relational monstrosity and all the GUI to go with it. There's still a few tasks that require direct table hacking (like adding completely new services and applications to the database), but overall I get a lotta compliments on it when I show it off.
It's very vertical though... it works the way WE work, and it has many things that would not work with a generic business... for example, it's integrated directly with our Radius database, and has several hacked scripts to keep the accounts updated and synchronized when modifications are made in accounting.
I'm personally a proponent of in house billing systems... for small businesses. For medium sized businesses I'd go with a prepackaged solution because it probably has a ton more thought with regards to all the various tax rules, interstate commerce, etc (which we don't need to worry about), and of course large businesses are almost always custom.
Raven
And my soul from out that shadow that lies floating on the floor
"I will trust Google to 'do no evil' until the founders no longer run it." Hello Alphabet.
Of course you can trust it, silly person! You can read the source code. The real question is why anyone trusts closed-source financial systems. Yes, I know: the reputation of the author. But that applies to open source as well, so it's nothing special.
-russ
Don't piss off The Angry Economist
Somebody has to slaughter the vegetarians....
Don't piss off The Angry Economist
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.
Its true that there are a lot of people providing these kinds of services via http (another is Worldpay for credit card validation). And the OS aspect doesnt matter that much as long as there is an open API. Whats bugging is that there is no standard for:
1) submitting your data to them
2) getting their response back
3) formatting direct-to-user responses
4) TESTING!!! (worldpay don't provide anything you can test with from inside a firewall)
(the 3rd category happens in one of Worldpay's payment models - the user fills their details directly on Worldpay, they send you an email so you can fulfil the order; but their pages are butt-ugly and you only have a limited set of tags for customising their content.) So you end up having to rewrite everything to use a different payment clearing house.
Soap. ebXML. XSL. Come the revolution...
I didn't say it. George Orwell said it and he was talking about real capitalist societies and real collectivist societies that he witnessed himself. These are observations what what we as people make of our ideals.
How we know is more important than what we know.
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?
How we know is more important than what we know.
I did indeed misinterpret the question. Of course, in a perverse way, you could set up Interchange to do some of what he wants, but thats outside the point entirely.
As to your Akopia problems.. The Interchange install went very well for me, what problems did you have? Or did you have problems with the installation of things like apache, php, etc., none of which are the fault of interchange?
GPL'd web-based tradewars themed space game
If you take a peek at Akopia, 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?
GPL'd web-based tradewars themed space game
To go along with this, if anybody has open source shipping cost calculation software that they would like to recommend, many of us would appreciate it.
WarpCharge is a credit card transaction processing system. It receives requests from the web server to do CC validation and charges, and it uses a third-party (in this case, Electronic Clearing House) to perform the actual validation/charge, so you'll need an account with ECHO.
--
And the men who hold high places must be the ones who start
To mold a new reality... closer to the heart
I'm in the process of writing an apache module w/ Win32 client to do just this. NO ONE makes *really* nice out of the box solutions, if you want something that looks professional in this department, you have to do it yourself. I've evaulated aproximatley 10 or 20 peices of software, even if I did use them, I'd have to severly hack them up.
Read the license for most commercial applications. You can't sue them either.
This is one of the most stupid misunderstangings about opensource.
Ring brother, ring for me | Ring the bells of hope and faith
Ring for my damnation | I am at the gallows end
I work at an ISP and we were using an old UNIX version of Filepro for a while when we decided to switch over to freeside. Freeside is good if dial-up is all you do, but we also resold DSL and do wireless. Integrating all of that in freeside was more trouble that it was worth. We practically had to re-write the whole thing to get it to work and then that wasn't even that great. We ended up purchasing a solution by a company called boardtown. The system is called platypus and has been working great thus far. It has all the built in integration for radius, and is very easy to create scripts to run on servers.
Rick Kukiela
Depends on your clients! If you are in a situation (which I presume you are) where you can "control" the client's, how about using html as your print format. If you know the browser you should be able to design accurate and flexible enough pages.
I did create a system for filing Irish companies in perl::CGI where government forms were required amongst other things and the solution worked fine (I enjoyed firing Netscape onto 20 Win9x boxes to let them use and print from it). If you have something bizarre html might not do you.....but I doubt it! The only quirk I had left to solve (before we parted company) was getting landscape printing sorted properly...anyone have any ideas for that (that don't require any user input)?
Never underestimate the dark side of the Source
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.
"You can't get something for nothing." - my grandfather, on the stock market and Reaganomics.
Sure, that's easy. I'd post it here but the lameness filter keeps complaining... ;-)
(I'm just joking btw, unless you want a tv-late-night-commercial-billing-system that always says, no matter the product or service, that it is "only 19.95 plus shipping and handling".)
--
News for Geeks in Austin, TX
Sure sounded like a troll to me as well. That whole open source means free (false), so open source developers are a bunch of commie pinkos (false) argument. By using your wholely uninformed and ridiculous methodology, one could also argue that closed sourced software is created by a greedy capitalist profiteers who will intentionally introduce bugs that don't show up initially so you will be forced to buy their next product that offers no improvements. Or hell, they could be so greedy, they could also introduce backdoors so they could spam your customers, steal your business, etc.
The point is, your argument implies that someone would go to the trouble of developing a huge, complex piece of software merely to sabotage it. Any maniac that actually would waste the time to do that would either be a) Unknown, and therefore there is little chance of the software getting a good word of mouth (are you going to use mission critical software you've never heard of?) or b) known to be raving lunatic. You can argue that you weren't trolling, but you might save your reputation as a critical thinker by saying you were ; ).
"We obviously need a new moderation category: (-1, Woo-fucking-hoo)" --Mr. AC
Vegetarian Slaughterhouse sounds like a good idea .... then maybe they'd stop pestering me when I'm eating my dinner at McDonalds ....
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
Isn't this a paradox? Surely everything should be free? Open Source Billing Software sounds like Vegetarian Slaughterhouse to me.
Wanting to go open source is not always about money. I go opensource in everything I can and will search long and hard for a opensource solution. The firms I work with can more that afford closedsource alternatives. The issue is control as in who has it and I feel that any business that would give control of their software to another company does not understand the issues involved. This is why I know use the term open source instead of free. While free is more accurate opensource better convays the idea that it is about the source not the cost. That having been said having freeside set up configure and train you on their opensource product is a great idea.
Cypherpunks: Civil Liberty Through Complex Mathematics. Those who live by the sword die by the arrow.
You beat me to it. Absolutely, positively, DO NOT use MySQL for financial transactions. MySQL is fine for a lot of tasks, but not ones where data integrity is critical. Not only the lack of transactions, but also the lack of foreign keys/referential integrity.
And please, to all of you who are about to post "hey, I process 2 million financial transactions a day at a major bank using MySQL, and it works fine", please spare us. The issue is not how good is it when everything is working well, the issue is how good is it when you get a massive hardware failure.
--
Sometimes it's best to just let stupid people be stupid.
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
ich bin der musikant
mit taschenrechner in der hand
kraftwerk
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. 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?
---
Video meliora proboque deteriora sequor - Ovidius
That said, I have since switched to just using Quickbooks Pro, 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) 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 may fit the bill. Good Luck.
--It's Pimptastic!--
Although, the are more ecommerce focused. Zelerate
The reason for this is that, quite simply, MySQL does not support transactions. Transactions are a set of operations that are either all executed or all fail. This ensures that a customer's credit card is only billed if a service is provided, and vice versa. Without transactions, you will never be able to tell what went through and what didn't. And of course, since MySQL stores databases as directories, we're not dealing with the world's tightest encryption either.
Take my advice, and go with a transactional database. If you're so obsessed with the open source model, go with PostgreSQL - it's actually open source, not just free software like MySQL.
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...
The next Slashdot story will be ready soon, but subscribers can beat the rush and slashdot the links early!
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.
Tim McEwen has written a billing service that will handle all of his eCommerce and hosting accounts. It will automatically send email, paper, and other (?) notification of monthly charges. It keeps regualr track of all incoming and out going statements. It currently is running on an Apache System supported by mySQL. (did I get that right?) I know that this is part of his regular business of eCommerce, but he may be willing to let an individual (or 2 or 3) have it if there could be a mutual agreement reached. Please contact Tim at his customer service e~mail
.