Why Reinvent the Wheel?

If you're a manager with any type of responsibility over a project that touches ISO8583, it doesn't make any sense to avoid jPOS.  The ISO8583 packaging/unpackaging effort has been solved by Alejandro in the jPOS Open Source offering.  If you're not using it, it just doesn't make any sense right now, especially if you're chartered with building a new payment systems solution.  By not considering jPOS, you're adding more costs, more time and opening yourself up for errors and processing holes.  Trust me:  we have one remaining legacy system we support and we're still finding holes in the ISO8583 processing some 15 years after go-live.  Plus, with jPOS you get the power and resources of the jPOS community - collectively, we've implemented thousands of ISO8583 interfaces across the world, with every little variation and twist you can imagine.  All that thought and experience has been assimilated into successive iterations of the jPOS project offering.  And the jPOS mailing lists (users, developers) are great resources to pose questions about your specific needs and requirements.  Why re-create that wheel?  Why stand in a silo, trying this by yourself, with nothing but the echoes of your own voice?

Who's using jPOS?  You can see a starter list here.  What's important are the names you don't see - we see the downloads and answer some direct, follow-up questions.  We know Fortune 500 acquirers are using it, big processing gateways are using it, and the big IT consultancies are using it.  And, hey, news flash: if you're considering a software vendor package, there's a good chance they're using it as well (but why would they tell you?).

What we're seeing right now is that savvy individuals and developers who know how to target, navigate  and integrate Open Source projects are getting into these large companies and changing the DNA.  Who are these people?  You can read some thoughts about their characteristics in my previous posts about "Building the Team" (part 1, part 2).