Open Source Billing Solutions? 156
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.
Billing (Score:1)
Re:I have an "Ask Slashdot" question, too (Score:1)
Flavio is obviously a flamer.
Re:Difficult to install perl modules? Let's be rea (Score:1)
Re:I have an "Ask Slashdot" question, too (Score:1)
One opinion of which is that we should evidently go to Freshmeat. Seems only fair to let him express *his* opinion. And /. *does* do stuff that isn't news for nerds a little too often...keeping them on track is a valid activity.
Re:I had to roll my own. (Score:1)
We ended up rolling out our own system that did not care what service was being rendered, it simply billed in realtime (1 second granularity). The entire spectrum of services was divided into two categories, fixed price per unit time regardless of use and variable price per unit of usage and time. Most routers are capable of providing such detailed usage information that you can actually develop plug-in modules to charge your users according to number of bytes they uploaded or downloaded.
The bottom line is it is technically possible and feasible to come up with a plug-in based approach to standards driven billing, no matter what kind of service is being provided as long as there is a hook available in the physical devices to provide usage information.
Faraz
Why? (Score:1)
I have an "Ask Slashdot" question, too (Score:3)
http://freshmeat.net/search/?q=billing [freshmeat.net]
I anxiously await my answer.
-- Flavio
Re:DIAMETER ready (Score:1)
WHAT????? I think you better check again. Radius uses TripleDES Encryption between server and client for ALL communications.
Have you even Read the question? (Score:1)
Re:Excellent solution available (Akopia Interchang (Score:1)
Re:Excellent solution available (Akopia Interchang (Score:2)
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.
Re:Difficult to install perl modules? Let's be rea (Score:1)
Re:Are you sure you could trust it ? (Score:2)
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?
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.
Re:Are you sure you could trust it ? (Score:2)
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 [portal.com], but then you find someone [liveoaktelecom.com] or other [primal.com] with a clue.
Life goes on. If was easy, we wouldn't call it "code."
Re:Are you sure you could trust it ? (Score:4)
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.
Free billing software (Score:3)
Karma karma karma karma karmeleon: it comes and goes, it comes and goes.
we rolled our own (Score:2)
Re:DIAMETER ready (Score:1)
--
Harder than it sounds. (Score:3)
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.
We wrote our own but it wasn't usage based (Score:1)
They were very pro NT and used Allaire's ColdFusion which I had to learn.. but I did it.. and wrote an administration and billing system.
We were setting up as an e-commerce solutions provider (which sounds posh now but means jack). The billing system allowed us to bill one off charges as well as taking care of variable period recurring charges. Customers received an email telling them that a bill had been produced. They'd view it on line and print it themselves from their browser if they required a paper copy. Payment online via credit card. Worked a treat.
Off the shelf accounts packages don't often deal with recurring charges. Billing packages do but it's $$$s (or £££s in our case).
We were a start up on a low budget, rolling our own worked for us. An export to a regular accounting package kept the finance director happy.
Seems I'm not the only one in here to have had experience with home grown billing systems.. I hear you with "Real databases! No transactions in MySQL! You get what you pay for!" rally calls.. but it seems by reading all the other posts that it can be done cheaply and effectively..
Again, just my £0.02
Re:Are you sure you could trust it ? (Score:1)
ergo... if you don't understand the source code then you can't trust it any more than closed source software.
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.
I don't think so... if you're a company making money specifically off software that the company created then you *very much* care about your reputation - it precedes the ability of your software to do the job as a requirement.
As an Open Source developer you may or may not care about your reputation... its up to you.
another open source package (Score:1)
The first, which a few people have mentioned, is freeside, which is written in perl and seems to have a pretty active mailing list. The author is usually pretty quick to help, and he will consult if people want to hire him.
Another package which I doubt anyone has mentioned is ISPD at http://ispd.eburg.com/. It looks like it does a lot of the same basic stuff that freeside does. One issue, though, is that the project appears to have run out of steam from the look of the web page.
I doubt you'll find much more than this. Billing software is hard to get right, and not especially exciting.
Difficult to install perl modules? Let's be real. (Score:2)
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.
--
Why no Free Bear? [Offtopic] (Score:1)
Why Free Speach but no Free Bear? I want my Free Bear, dammit! ;)
Re:MySQL Backend? Get Transactional! (Score:1)
I have been implementing databases and designing systems like this for years in the medical industry and let me tell you that there is nothing more annoying than having to use the wrong technology and write extra code to work around the lack of functionality. Save yourself the headache!
Dissenter
ISP Billing packages. (Score:1)
The first ISP I worked for was a large, national ISP, who got their entire customer base from buying out various local ISPs across the country, then began buying time on UUNet dialups to provide "national" service. The lovely thing about this, is when I worked there, all these smaller ISPs each had their own billing package. (I beleive that since I left, they have integrated into one system)
I dealt with 3 packages while working there. Two were rather awful. One of these was simply a command typed at a shell prompt which dumped you into a very feature-poor program with a pretty poor interface for moving aroung. The second was accessed by telnetting (Yes, as insecure as that was. Not to mention the box we were telnetting to was across the country from us, and god knows how many people could have packet-sniffed it) to a particular server, which dropped you into a menu based system. (Select 1 for this, 2 for that, etc)
The good package I used while working there was entirely web based. Security was handled by SSL and htaccess, and you had to have an interal IP to hit the site as well. The system allowed you to run SQL queries on pretty much any field you could think of. Needed to look up the number of customers in city X with a phone number having prefix 555? No problem. (This was completely written in Perl, database was MySQL. All running on FreeBSD.) Best package I have ever used, but the company isn't going to be releasing it to the public any time soon.
Now, at my current company, I have used two. The first was in-house, accessed again by typing a command at the shell prompt. Decent interface, but still feature poor. A web interface was also part of it, for tracking customer history. No database, just flat files. Sloooow...
We have now moved to a commerical package called Emerald [iea-software.com]. This gives you the pretty Windows GUI, but requires you to run MS SQL 7 (Not 6, not 8, not Oracle. I'm not sure why it is so picky) as well as an NT radius server. (This company was 100% Solaris when I started there, with Windows on the desktops)
Now, the operations staff wasn't exactly happy about this decision, and we are still pretty paranoid about the NT boxes' security. (Which is why they are buried behind firewalls) The decision was made so the accounting department could have a pretty windows interface, and so we could ditch the in-house package the company had completely outgrew.
The software is very feature-rich, letting you do all kinds of neat tricks and reporting. Let's say someone forgets to pay their bill. You can have the system let them log on, but allow nothing to work but web traffic, and redirect them to a page telling them to call in and cough up the cash. The interface, however, is kludgy, slow, and quite the memory hog. In-house, a web-based (perl again) interface is being developed so we can ditch the crappy interface it comes with. Another note, the software is *very* expensive. (Some tricky things also had to be done with perl scripts to get around the fact that the software wants you to run a Windows mailserver. No way we were going to take on that security risk, as well as give up on the excellent mailserver that is Qmail.)
-Wintermute
Re:Are you sure you could trust it ? (Score:1)
Re:Free billing software (Score:1)
--
Arsdigita for online e-commerce (Score:1)
Re:Are you sure you could trust it ? (Score:1)
My company (large business ISP in the UK) took that road when they decided that the legacy billing software we got from our parent company in the US wouldnt be Y2K compliant and needed replacing. We hired several programmers and started to design a SQL database driven ISP solution. 2 years we had spend more than 2 million dollars and the project had been canned during final beta stages.
My point is that if you think that with just hiring a few programmers to tailor OSS for your needs will do it, then you're very much mistaken. A project like this needs to properly managed, you need a large userbase for beta testing (believe me that costs handsful of money). ...
In hindsight we could have bought a software packet that did all we wanted for $100K, with support and all
I think that the post above only makes sense in an ideal world (what sane ISP jumps at the chance to run the latest Apache? (I know of none that runs 2.0ax), but this is the real world, where things always cost far more than people think, and with OSS I feel the costs are more hidden than with off-the-shelf packages, making it an unfair comparison.
--
Full Time Idiot and Miserable Sod
Re:Are you sure you could trust it ? (Score:2)
Read the code? (Some people are idiots, I swear.)
-- Crutcher --
#include <disclaimer.h>
Our in-house solution. (Score:3)
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.
In House (Score:2)
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
author response (Score:1)
figured I'd give a try at responding here.
Security: "alot of suid scripts and suEXEC in
Apache" is incorrect. More properly, it's
suid *OR* suEXEC in Apache, *OR* one of the other
methods outlined in the installation instructions
for running Freeside as its own user - a security
precaution, something I wish more packages which
handle sensitive data did. I've been securing Internet servers for almost seven years now. Freeside
is extrememly carefully written, and has never
had a privledge-escallating security problem. *EVER*. (You may consider that a challenge)
On the topic of neatly packaging the "3rd party" modules: it's been done, it's called CPAN, the
Comprehensive Perl Archive Network, and it's really very slick: http://search.cpan.org/ Also, I'm just finishing up the Debian new maintainer process, and all of the modules that aren't currently
way into Debian unstable, followed shortly by Freeside itself.
MySQL vs. PostgreSQL: The posters who pointed
out that transaction support is essential for financial transactions are
correct. Freeside has a Pg backend, and all
future development is focused on Pg, not MySQL.
Your other option for open-source ISP billing software, as the original poster asked: ISPD at
.
The irony of open-source _billing_ software:
I'm a vegetarian, too.
Real-time billing: One poster claimed that
"Telephony billing really needs to be real-time
rather than ISP billing which is just parse a load of scripts". The current CVS of Freeside
contains an SQL-based "session monitor" which
tracks user sessions in real-time.
Re:Are you sure you could trust it ? (Score:2)
-russ
Re:Open Source? Billing? (Score:2)
Re:MySQL Backend? Get Transactional! (Score:1)
use LaTeX? want an online reference manager that
Re:Are you sure you could trust it ? (Score:3)
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.
Re:Are you sure you could trust it ? (Score:1)
That said, if you implement a billing system, on which your business depends, and you don't have a manual audit process, you're a fucking moron.
Re:I have an "Ask Slashdot" question, too (Score:1)
Re:Open Source Shipping (Score:2)
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...
Re:MySQL Backend? Get Transactional! (Score:1)
Someone said that you need to do things in the right order to make sure stuff is OK. Yes, you do, but does this fix the case where n different things are trying to do the same thing in parallel, and exactly one must complete while all the others must be rolled back? And someone trips over the disk cable half way through this process. These things do happen, and since this thing is how you make money you want to be very sure you can recover from them.
As far as I can see there are two ways to do this kind of thing: either you serialise access to the database by large-scale locks, together with some kind of rollback system, or you have a hairy transactional system. The former solution is OK if you don't have very high throughput, or if the load can be easily serialised, like some kind of run-nightly batch system. If you have high throughput and lots of parallel updates, then I think you're either going to end up either writing or obtaining a transactional system or going out of business at some point when the system eats your data.
Re:Dole queues (Score:2)
Who contributes? (Score:4)
Re:Same Situation (Score:1)
Re:Open Source? Billing? (Score:1)
There is no irony here. Open Source is a development model, not a business model. Not to mention all the pundits that would note that open source != free. Again, the distinction between the development and business sides of the industry.
--
How about PalPal? (Score:1)
My understanding is that it's pretty much run on the PalPal servers and is a pretty simple link to your system.
free open source billing software (Score:1)
I think Billing and CRM systems are extremely critical to your business and you should probably invest money towards this side of your business. Try Singlularit.e OSS suite from ADC. They have an excellent Billing Engine (SavilleExpress) bundled with an extremely configurable CRM product (SavilleCare).
aditya
Re:Perl is not the issue. (Score:1)
--
NeoMail - Webmail that doesn't suck... as much.
Re:Excellent solution available (Akopia Interchang (Score:2)
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?
Excellent solution available (Akopia Interchange) (Score:4)
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?
Open Source Shipping (Score:2)
Re:Open Source Shipping (Score:2)
I ended up importing the csv files from UPS and Fedex for our shipping location into a MySQL database and writing a Java API (mmmm servlets) to compute shipping based on this. It works well for a single shipping point for shipping within the US. It breaks down when you want to ship outside the US or add another shipping location. The hard part is importing the data but once that is done, it runs really well.
If anybody wants the code, I can GPL it give it to you. Just send me an email. I am however looking for a better solution or if I ever get time, to extend my package.
Re:Open Source Shipping (Score:2)
Re:MySQL Backend? Get Transactional! (Score:1)
Hint: Half the rows are written, half aren't. Nothing that knows whats going on is still running.
A transaction based system would either re-apply (WAL) with ensured integrity during database startup, or give up (ROLLBACK) transaction where the database was still live.
When hiring, first thing I look for is the lack of MySQL on the resume. Why? I care about my data.
Re:Open Source Shipping (Score:1)
Intershipper.com has an open API, but they're unreliable, sadly.
UPS (and I think FedEx also) will allow you to download API documentation and reference source code to interface to their servers for realtime calculations. You have to register to get the download, and AFAIK the license does not allow you to incorporate it into an open source product. I have seen a PHP implementation floating around the net though...
--
Re:Open Source Shipping (Score:1)
If
--
What to stay away from (Score:1)
Being a former ISP startup guy (first in a six-state region - yea) and having spent the last 2.5 years for a larger long distance company, I headed up our search for billing solutions. Here are some things to avoid:
- Convergence: Lots of the billing companies talk convergence (meaning you can bill for radically different things, like long distance, local service, Internet and cable TV... wow!), but until you've seen the code in operation, don't believe them. Convergence to many (like Lucent's Kenan division) means "if you pay us $6 million, we'll start writing code and bill you $350 an hour additional to develop something convergent." Avoid like the plague.
- Big/old vendors: These guys aren't struggling, but most of their new customers are. In fact, the only people I could find doing well on systems like Kenan and Saville were the RBOCs. Must be one of those paradigm things - and trust me, you're not of the same paradigm as they are (thank god).
- Little startups: Some of them have great ideas, but unless your vendor is CMM 2 or greater [cmu.edu], they'll have a snowball's chance of being able to manage the system as it grows. There are a couple of notable exceptions, but these are startups that have understood managing complex processes, application design, project management, etc. (Two of the notable exceptions I came across were Telution and Daleen, both competent vendors albeit focused on NT solutions).
- Add-ons: This seems to be one of the games the billing companies play. They know you're not a billing expert, and will leave out tons of things to nail you for later. "Oh, you actually wanted to import Radius data into the system? Oh, the package you bought just bills. You need our $500K mediation package to do that."
- Turn-Key Claims: Most of the bigger boys claim they have turn key packages. What that really means is that they send a dozen programmers, at $350/hour, and get them programming at your location for a half year to write a custom application just for you. Believe it or not, many of the guys who've been in business quite some time don't have anything more than a source library and an Oracle database, which they write a custom application around just for you.
- Integration Labor: Watch this like a hawk and specify in your contract that billed hours don't count unless they're itemized and approved by one of your senior people each week. Our company got its first notice of where it was at with its integration when we got notified that all the hours were used up - and the vendor hadn't even been on site yet! Make sure you specify that they're responsible for a delivered product within those hours, or the overage is their expense (otherwise you end up paying to send their people to tradeshows and golfing in Vegas, as we did).
- Support Contract: You know the pitch you get at your local Best Buy/Circuit City about "for only $69.00 you can add three years of maintenance on that cd player" - support contracts are the margin booster for billing companies. Don't buy open ended contracts - prefer to pay by hour. My experience has been that service has actually been better ala carte.
- Expenses: Most vendors dump travel, lodging, etc. for every visit they make into being your expense. That's fine, as long as you control it and approve where they go, when they come, etc. (When your vendor expenses $350 a night in Omaha Nebraska, something is wrong).
- Revenue-based, Subscription-based, or Seat-based license: Lots of vendors include an "annual license fee" - which means you get to buy their software year after year. And the fee goes up as you grow revenues, number of subscribers, etc. Avoid this, since when you look at the overall billing cost per subscriber, you end up negating any advantage of growth in your subscriber base in many cases.
- Be Creative!: Lots of things (especially the add-ons) can be done in house by your own people for a fraction the cost. Lucent sells a mediation package called Billdats that downloads records from phone switches and puts them in a central space. It uses dedicate x.25 connections to each switch, which cost you an arm and a leg, and last time I was told, it still didn't have support for IP. Save the $500K and buy a really nice Linux or freeBSD box for $20K (lots of drive space). For extra money, Billdats can sort records (grep, comes free in Linux/freeBSD), Billdats can convert from one call record format to another at $70K-$80K per custom format (Perl can do it for your programmers in a couple of hours, $200 probable cost), etc.
Sorry to be so wordy, but I am overjoyed that someone else brought up the topic of open source systems. We did that with our mediation instead of buying Billdats. Funny thing - I showed the Lucent Billdats people our system and said we'd consider theirs if they could beat our little $20K box. Oh, theirs doesn't even come with hardware...
Most of these billing vendors thrive on selling a poorly documented product, not allowing you to maintain it yourself (source code? you should see their response when you ask for it!), charge $350 an hour or more for a half dozen $30K a year interns to learn on your time, and provide horrible support. ISPs that can avoid this have a much better chance of surviving.
But the rest of the billing, provisioning, print-house, and related functionality needs to be included as well. If anyone's interested in a coordinated open source project, email me (scoove@americanrelay.com) - I'm game.
*scoove*
Re:Open Source? Billing? (Score:1)
1. developing yourself using their APIs (which usually get documented by a disgruntled unpaid intern). Chance of success: slim
2. developing yourself and talking right to the database. Chance of success: good, except you'll probably invalidate your support contract and possibly hoze up some of the vendor's application.
3. having them develop for you. Chance of success: good, but cost is high and delivery timeframes usually poor.
Also, open source allows you to survive when you either nix your contract with the vendor (so you don't pay annual extortion fees), or they go out of business (which happens on occasion).
*scoove*
Re:Are you sure you could trust it ? (Score:1)
We've gotten calling card platforms that were textbook cases for undocumented disasters. Security holes all over the place (thankfully we put them behind as many barriers as possible and never operated them on any public networks, but I've found plenty of the same system sold to other companies on public IPs).
Disgruntled vendor programmer leaves, visits the boxes, and issues himself $100K in calling cards that he sells on the street in NYC...
Happens in closed source, and unlike open source, you have no chance to find the holes and fix them.
So, which would you prefer?
*scoove*
Re:Are you sure you could trust it ? (Score:1)
Sure it is, but proprietary code is backed by legal liability.
have never bought major commercial software systems. I've got five calling card switches from a worthless vendor who shall remain nameless (and a pack of vicious wolves couldn't drag it from me) [prioritycall.com] that goes down weekly, was written by a couple of contracted college students long gone, horribly documented, and has cost significant revenue loss.
Their response to our troubles? Besides regularly losing trouble tickets and having monthly turnover in their NOC? "Sorry. Your contract says we're not liable other than the cost of the software."
So where has this proprietary software saved me? Oh, and before the response "don't sign a contract that gives away your rights" is made, you try buying anything and specifying that the vendor's boilerplate license gets tossed...
*scoove*
Perl Modules (Score:1)
Re:Are you sure you could trust it ? (Score:1)
Um... Seems like you never read EULAs they basically also tell you that you get the Software "as is" reads: If it doesn't work, you're out of luck.
Or to put it differently: You are as much screwed with closed source software as with open sourced one. The big difference just is that you can fix the open source yourself (if you know how to program, which in my case doens't make much difference).
The real problem with Freeside. (Score:1)
Yes, Freeside uses a large amount of perl modules and that can be a pain to get all of them installed and functioning correctly, but that isn't too bad. The real problem is the configuration of Freeside itself. The project simply has the worst documentation I have ever witnessed in any project anywhere. There is little documentation available, but what documentation there is makes little sense at all. Don't get me wrong, I have no problem with reading and comprehending even poorly written documentation, but there are limits, and Freeside surpasses them.
WarpCharge (Score:2)
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 [echo-inc.com]) to perform the actual validation/charge, so you'll need an account with ECHO.
--
I had to roll my own. (Score:2)
Re:What a sucky troll (Score:2)
Read the license for most commercial applications. You can't sue them either.
This is one of the most stupid misunderstangings about opensource.
Re:Are you sure you could trust it ? (Score:1)
Actually, if you're paying $100K for some software, your legal team better make sure you put up the extra $500 or so to put a copy of the source code in escrow in case the software company goes belly-up
(Isn't this the point in the debate where someone claims that a billing system can be written in 10 lines of Perl?)
Dang - I could only get it down to 12. ;-)
--
Re:Billing (Score:1)
Billing (Score:2)
Rick Kukiela
Re:Hmm... (Score:1)
So in this case it seems that the guy is going with Open Source Software for the very reason that he cannot afford the commercial software. One of your very bullet points.
Re:surely he must have a budget (Score:1)
I do agree though, that he should have considered the need for a billing system and factored that into his budget in case he couldn't find an Open Source or Free billing system.
Re:Same Situation (Score:2)
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)?
Those who are smart? (Score:3)
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.
Re:Are you sure you could trust it ? (Score:1)
Oh.. I don't know, could do something radical like look in the code ???
billing system in 10 lines of perl (Score:2)
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".)
--
ISFree Yes another exists. (Score:1)
Theres several other issues that I won't get into for the sake of avoiding bashing unnecessarily since this is about finding solutions instead of problems with freeside.
ISFree doesn'thave a website and it's only 40% designed and 10% written. It's being written with lib-gcgc, in ANSI C, and supports full transaction abilities. I started actualy writing it 2 weeks ago after loosing access through the FreeSide web interface to all my customer data. I'm trying to preserve the generic services ability that freeside has. I'm also trying to set it up so that you can use it for ALL your accounting. From billing to payroll, to expences.
I DO need some help writing it if it's going to be in alpha state within the next couple of months so far as billing side.
NOTE: ISFree is 100% GPL, and as close to ANSI C as I can make it so that it will work everywhere and can easily be extended.It will allways remain GPL.
For those of you who want reasons not to use freeside feel free to email me. Ill gladly relate my experiences with freeside and it's coders.
Re:ISFree Yes another exists.- website added. (Score:1)
http://isfree.terrabox.com [terrabox.com]
Re:Hmm... (Score:1)
It's like there are tens of thousands of Stallman clones, who have neither the education or intellect. The not-so-endearing term "sheep" comes to mind.
Paying for software is sometimes a GOOD THING!!
(Oops, -1, Flamebait)
Re:What a sucky troll (Score:2)
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 ; ).
Re:Free billing software (Score:2)
No irony. Better yet, I'm not even going to resort to that tired point about Free Speach vs. Free Beer either. I've never bought that argument anyway.
Instead, I'm going to point out that the job of an entrepreneur is to take raw materials, turn them into finished goods, and receive profits in return.
It's natural for an entrepreneur to seek raw materials at the lowest possible price. Indeed, as a nascent software entrepreneur I stumbled into my first experience with Free Software because I typed "Free JPEG code" into a search engine. Much to my surprise, I found some.
Now, the time during which any piece of software is of interest to an entrepreneur as a pure product (as opposed to being bundled with some other product) is limited by how quickly Free Software implements something comparable. This doesn't make entrepreneurs, even software entrepreneurs, seeking free software a study in irony. It just makes them shrewd buyers.
Re:Open Source? Billing? (Score:2)
Vegetarian Slaughterhouse sounds like a good idea .... then maybe they'd stop pestering me when I'm eating my dinner at McDonalds ....
Industry-wide Problem (Score:3)
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
How about membership/attendance software? (Score:1)
Re:I had to roll my own. (Score:2)
However, there are real problems inherent in the approach. Telephony billing really needs to be real-time rather than ISP billing which is just a parse of a load of scripts. I can see the concept, I'm just having problems seeing how you can make this as flexible as you want it to be....
Re:Open Source Shipping (Score:3)
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? (Score:3)
Re:Freeside Solutions (Score:2)
Re:Oxymoron (Score:2)
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.
--
Oxymoron (Score:5)
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 (Score:5)
---
The good and the bad. (Score:3)
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.
Check out Zelerate also... (Score:2)
MySQL Backend? Get Transactional! (Score:2)
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.
Write your own... with some cautions (Score:3)
Unfortuneately, the second version was written by programmers *for* programmers. It didn't go over very well. I think they have refined it since...
Re:MySQL Backend? Get Transactional! (Score:2)
comercial billing is where it's at (Score:3)
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.
Perl is not the issue. (Score:2)
Contact the following... (Score:2)
.
Re:I have an "Ask Slashdot" question, too (Score:4)
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.