Slashdot is powered by your submissions, so send in your scoop

 


Forgot your password?
Close
typodupeerror
×
The Almighty Buck

Open Source Billing Solutions? 156

Posted by timothy from the surely-they-can't-be-alone! dept.
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.
This discussion has been archived. No new comments can be posted.

Open Source Billing Solutions? More

Open Source Billing Solutions?

Comments Filter:

  • Billing (Score:1)

    by Anonymous Coward
    Try IPMeter at www.ipmeter.com. It uses a few perl modules also but is pretty easy to install.

  • Re:I have an "Ask Slashdot" question, too (Score:1)

    by Anonymous Coward
    Hey Moderators wake up! This is as "insightful" as a goatse.cx link. Freshmeat doesn't provide us with anything on which billing systems others have had good/bad experiences with! Isn't the point of slashdot to hear the opinions of others?

    Flavio is obviously a flamer.
  • maybe he couldn't log in into the system. he forgot his passwd or something. Or he didn't switch the system on.

  • Re:I have an "Ask Slashdot" question, too (Score:1)

    by Anonymous Coward
    Isn't the point of slashdot to hear the opinions of others?

    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)

    by Anonymous Coward
    You hit the nail with your comment. Early on in my carrier (about 6 years ago), I worked for a data services provider in Pakistan and faced the exact same problem. We were not just ISPs, we were providing voice over IP (before it became illegal over there; non-competing clause with national telecom), TDMA, Frame Relay, Point to Point Wireless, Last mile solutions, VSAT, ISP and just about every data service you could imagine.

    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)

    by Anonymous Coward
    It seems to me that large portions of what you did were an exercise in re-inventing the wheel. Now while I'm a huge advocate of Open Source and homegrown software, and I know this comment will invite a GNU holy war, there are PLENTY of fine commercial accounting systems that are exstensible and could track ISP-specific data with little modification. Additionally, if you get bought up (as most ISPs do at some point) it will be less of a headache to do the conversion if your data is stored in some known, standard system rather than something you baked yourself. Accounting is probably the only area of business that hasn't changed much at all in the past 500 years, and the problem has been solved many times over by commercial software vendors. I think development time would be better spent writing some code that would track and dump your ISP specific data into other systems via some standard XML transaction format. That way, you could let the accounting software do what it does best, keep track of the money and run out invoices.

  • I have an "Ask Slashdot" question, too (Score:3)

    by Anonymous Coward on Monday January 08, 2001 @05:24AM (#523739)
    Is Slashdot now the formal replacement for Freshmeat?

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

    I anxiously await my answer.

    -- Flavio

  • transport of RADIUS data over a network is practicly in the clear (except passwords)

    WHAT????? I think you better check again. Radius uses TripleDES Encryption between server and client for ALL communications.

  • Yes, he used freeside, he said it sucks. To patchy!
  • Actually, I had makecat problems, it wouldn't always copy files into the dir's that I specified, I'd tell it the DOCROOT was /home/httpd/ and it would still copy into /var/www.... nothing major, someone prolly left something hardcoded in the script, just replace it with a variable.
  • 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.
  • Why was that moderated as flamebait? It's clear that jcostom knows what he's talking about, and that antis0c hadn't actually tried it.
    • 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 [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)

    by the red pen ( 3138 ) on Monday January 08, 2001 @07:15AM (#523747)
    • 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 (Score:3)

    by MouseR ( 3264 ) on Monday January 08, 2001 @05:23AM (#523748) Homepage
    ...anybody else feels the irony in this?

    Karma karma karma karma karmeleon: it comes and goes, it comes and goes.
  • My company [spinweb.net] 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.
  • I'd skip DIAMETER support and put my money on CIRCUMFERENCE?
    --

  • Harder than it sounds. (Score:3)

    by _Gus ( 5251 ) on Monday January 08, 2001 @07:21AM (#523751)
    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.
  • When a bunch of guys left my previous employer and setup in business for ourselves, we wrote our own billing package. Well actually, I did.

    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 :-) (anyone want to buy an administration and billing system written in ColdFusion?) ;-)
  • Of course you can trust it, silly person! You can read the source code.

    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.
  • I find this interesting since I used to work for a company that sold billing software for what we called "convergent communications carriers". I've been passively following a couple of efforts for a while now.

    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.
  • I've met the Ivan & his guys (the SISD guys that write Freeside) - great people, quality code. It's always nice to see hometown boys make good (he's also from the Philly area). All that aside, the questioner, antis0c, seems to think that installing perl modules is difficult. I just looked over the installation information for Freeside, and now think antis0c is nuts. Most of the modules are dependencies for larger libraries. You can knock out about a third of the list there by doing:

    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.
    --

  • I'm not even going to resort to that tired point about Free Speach vs. Free Beer either.

    Why Free Speach but no Free Bear? I want my Free Bear, dammit! ;)

  • Yes yes yes! I can't agree more! Some of the replies to this post have mentioned ways to code a manual rollback, but why? This is reinventing the wheel folks. Don't get me wrong, I know it's fun to hack out some code to make applications perform in ways they were not intended on our own time, but in a business environment the goal shifts from fun to profitability. Transactional databases are designed to perform this function. It's not like I'm telling you to run you server on NT with IIS. I'm recommending that when building a system like this, you not look for a work-around, but use systems that are designed to do what you want. Manually writing the code necessary to duplicate this functionality will increase the time required to design the billing system by a huge factor. The code will be longer and less streamlined and will cause the whole thing to run slower.
    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

  • Something I've had a lot of experience with. I've worked for two ISPs, and have dealt with 5 different billing packages. Interestingly enough, 4 of them were developed in-house.

    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
  • Maybe I read you wrong, but you seem to be saying that the Open Source movement is anti-profit. I disagree. I think it is about the free exchange of ideas. The profit comes riding in on the tail end of that (as opposed to on the bottom line), but it is still acceptable to make a profit.
  • There's a subtle difference between free as in beer and free as in speech. Thus vaporeth thy point.

    --
  • Check out Arsdigita [arsdigita.com] and read Phillips notes on e-commerce in "the book". You can use the ACS to take care of this stuff, when it's credit card based.
  • I'm sure the better way is to invest those $100K to improve NetFoo v.0.1. You gather vendor independence and freedom for the same price. There are lots of programmers, that can suit the open-source software for your needs. And you can sell it then as a solution (while still being open-source), because your programmers know it and you'll get something from the $100K back. That's what I call buisness
    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

  • >> 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>

  • Our in-house solution. (Score:3)

    by RomulusNR ( 29439 ) on Monday January 08, 2001 @08:17AM (#523764) Homepage
    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.
  • 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
  • Hi, I'm the primary author of Freeside, so I
    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 .deb packaged are about to make their
    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.

  • 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
  • Somebody has to slaughter the vegetarians....
  • i agree with you about the trasaction business, but as for the open source thing i do not. last i checked MySQL is open source. ie you have access to the source code. please correct me if i am wrong.

    use LaTeX? want an online reference manager that

  • Re:Are you sure you could trust it ? (Score:3)

    by spankenstein ( 35130 ) on Monday January 08, 2001 @06:06AM (#523770) Homepage

    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.

  • No, we're not. The post was talking about a guy starting up an ISP. Moreover, he was willing to consider an option that uses MySQL as the backend. The guy is clearly not in the market for a $50k-$100k vertical market billing system. That said, even at 50k-100k, you're not likely to get much in the way of a performance guarantee, and you're sure as hell not going to get strict liability.

    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.
  • 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 think that this (and some other messages here) kind of miss the point. For many billing-type applications the billing system *is* how the organisation makes money. So it's *really* important that things don't crash, but it's even more important that when they do, or when somebody does something funny, you don't lose data or leave the database in a bad state.

    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.
  • 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.

  • Who contributes? (Score:4)

    by QuantumG ( 50515 ) <qg@biodome.org> on Monday January 08, 2001 @06:19AM (#523776) Homepage Journal
    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?
  • I ran into this also, although I'm using Python instead of Perl. I thought LaTeX would work, but I couldn't control the output enough. I needed to place an address at a precise location on the page, so that it would show up in a window envelope. I ended up using Lout. My python script opens up a pipe to the Lout command and then feeds it a Lout formatted document. Lout formats the page in Postscript and outputs it straight to the printer. Works very nicely.
  • Not sure why this has been scored as Funny. It really isn't.

    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.

    --

  • Why not? They pretty much seem to be the accepted "small payment" system ... and when I saw Pud using them for the memorial fund on f*edcompany I figured they must be O.K..

    My understanding is that it's pretty much run on the PalPal servers and is a pretty simple link to your system.
  • sounds really funny! ironical rather.
    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
  • Gotta go with you on this one... Too many people inherently freak out when they hear suid. It got so bad for me for a while that I had to put a special section on my software's homepage addressing precisely this question.
    --
    NeoMail - Webmail that doesn't suck... as much.
  • 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?

  • Excellent solution available (Akopia Interchange) (Score:4)

    by iamsure ( 66666 ) on Monday January 08, 2001 @05:22AM (#523783) Homepage
    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?

  • 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.
  • Neither the Fedex, or the UPS solutions seem to be very cross platform. Furthermore, you would have to run both systems as neither calculates shipping for the other.

    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.

  • Yes that part is easy. The problem is of course getting the files to have the same fields. UPS and Fedex do things differently. They both work on "zones" but the zone tables (zip to zip) are cumbersome and hard to work with without quite a bit of formatting. Also the rate tables need to be massaged a bit. To save space, it seems that some of the columns are bunched together: zone1, zone2, zone3-4, zone5-6, etc. Blah.
  • I'd like to see you do an error check during a power failure or a system crash.

    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.
  • 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.

    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...


    --
  • 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 .csv means 'Comma separated values', then it shouldn't be very difficult to load the data into MySQL. Look at the documentation for the 'LOAD DATA INFILE' command, which is available in recent versions of MySQL. I found this out after I had already spent a day optimizing a CSV parser in PHP.

    --
  • While the topic is open source billing, you may find that at some point, the seasoned grey hairs (your ISP's board of directors or investors, for example) in the organization may press for a "real billing system" (read "monolithic ball-o-code that could have been written by Adm. Grace Hopper in 1963).

    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*

  • Exactly. Unless your vendor provides open source, you're stuck with:

    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*
  • Keeping things in perspective, how are you sure the proprietary, closed source stuff you got from the vendor isn't equally screwed?

    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*
  • Bingo. You nailed it. People who make claims like:

    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*

  • What's so hard about installing perl modules? Seriously, just run "perl -MCPAN -e shell" at your prompt. After you answer all the initial setup questions, type "install Your::Module", and it does it all for you. It even installs any prerequisite modules too. It couldn't possibly be simpler.

  • >>Free software has NO WARANTEE. No one said it was going to work correctly, so too bad for you if it doesn't.

    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 original poster was correct in saying that installing Freeside is worse than jumping through flaming hoops, but he was wrong as to why.
    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 [thetaband.com] from Theta Band Software is currently not open source, but the developers are working on making it so. You might want to email them to ask them when they will actually release 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 [echo-inc.com]) to perform the actual validation/charge, so you'll need an account with ECHO.
    --

  • 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.
  • > Who are you going to sue if your billing software breaks down ?

    Read the license for most commercial applications. You can't sue them either.

    This is one of the most stupid misunderstangings about opensource.

  • Try buying a billing system for $100K. You don't get a CD ROM in an envelope with a EULA stuck on the outside.

    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. ;-)
    --

  • I used to work for an ISP that used Platypus, and we ended up throwing the damned thing out once we started to go national, A lot of companies are starting to use in house developed products (we called our splatypus) because they can completely tailor them to their businesses.
  • 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
  • As Billing Software is a very specialised peice of software, it is very expensive, and I doubt that the guy has the money to buy a system unless he is a medium-large company with lots of budget to spend.

    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.
  • That seems to be what he is doing: Scouting vendors to see what sort of deal he can get. If he can get an Open Source (OR i'd assume, just Free Beer) Billing Solution that fits his needs, then that is going to be the best deal he can get.

    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.

  • 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)

    by re-geeked ( 113937 ) on Monday January 08, 2001 @11:50AM (#523806)
    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.

  • How could you be sure they had not put a back door in ?
    Oh.. I don't know, could do something radical like look in the code ???

  • 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".)


    --
  • I've used freeside for about 2 years.It's ok. It's also slow loading unless you take the day or two needed to install and configure mod_perl for apache.The biggest reason I refuse to use it is due to it's partial OO partial normal code, and it's inability to stably do transactions when working with a DB.

    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.
  • I've aded a simple website for people to check back on for the status of the packages. Ill be adding a webcvs link for ISFree. i won't be cutting any tar.gz files until it's at least partialy useable for trackign accounts and thier packages minimaly.

    http://isfree.terrabox.com [terrabox.com]
  • You need only look at the hostility the average /.er shows towards the concept of paying for software

    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)

  • 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 ; ).

  • 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.

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

    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)

    by TheFuzzy ( 140473 ) on Monday January 08, 2001 @09:08AM (#523815)

    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

  • I'm setting up an office for a nonprofit, and since we've got underpowered donated computers and no budget for this, Linux seems to be the way to go... but we're needing some kind of membership tracking software. We're already running MySQL, and I could write my own, but if there's something already out there that I could install (and possibly just customize), that would be spiffy.

  • Great idea, but the idea is really broad. It would be very hard to produce a generic solution that could allow for plug-in modules as you suggest, but I am intersted in at least working out the rough spec to see if it *could* be done.

    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)

    by Metrol ( 147060 ) on Monday January 08, 2001 @06:43AM (#523818) Homepage
    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? (Score:3)

    by Maggot75 ( 163103 ) on Monday January 08, 2001 @05:44AM (#523823) Homepage
    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.

  • 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)

    by CaptainZapp ( 182233 ) on Monday January 08, 2001 @06:29AM (#523834) Homepage
    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

  • 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. (Score:3)

    by TheFlu ( 213162 ) on Monday January 08, 2001 @09:25AM (#523842) Homepage
    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.

  • Although, the are more ecommerce focused. Zelerate [opensales.com]
  • I must confess that I have not dealt with many billing solutions before, open source or otherwise. However, I was in web development and e-commerce for a while, and I found that MySQL is a poor choice for any sort of billing database.

    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)

    by Bonker ( 243350 ) on Monday January 08, 2001 @05:30AM (#523863)
    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...
  • Actually, you are wrong about the open source bit. MySQL has been GPLed since June 28, 2000. Also, there is some new support for transactions thanks to NuSphere (they are contributing code that allows row locking) Read the story here. [mysql.com]

  • comercial billing is where it's at (Score:3)

    by foo(foo(foo(bar))) ( 263786 ) on Monday January 08, 2001 @07:00AM (#523874) Homepage
    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.
  • I would not be too bothered by suid Perl scripts. So long as they 'use strict' and have been put through taintperl or whatever they should be fine. You should be looking at other things from a security perspective. Like is the OS you are using secure ???

  • 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 [mailto]



    .

  • 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.

Slashdot Top Deals

With your bare hands?!?

Close