What is the Best Way to Start a Paid GPL Project? 231
pooslinger writes "I know little to nothing about programming but would like to start, fund, and maintain a GPL linux POS application. I see there are a few available with the majority being closed source. I am currently starting a business and really despise the fact that I will have to spend $2-$5k on a proprietary solution. I would like to create an application where you could take a midrange PC, connect inexpensive touchscreens, barcode readers, thermal printers, credit card readers, etc; scan/input inventory; and begin selling. Something like a Debian POS distribution that boots into X and starts a POS terminal. Does something like this exist, am I just trying to reinvent the wheel?" How have other people approached starting a new GPL project, finding talent, and ensuring the code choices best benefit the community?
PCI-DSS / PA-DSS (Score:5, Interesting)
PCI-DSS covers system and network security. PA-DSS (still in draft format, and perhaps still better known as PABP) covers software application security. There are also things like EMVCo if you're thinking about chip and pin cards, and APACS standards (in the UK - not sure what the US equivalent is) for message formats to and between acquiring banks.
Considering you state you havent even learnt coding yet, you will most certainly be jumping in at the deep end with this task. I've got around 10 years experience in the field, and the pace of change is... breathtaking. Good luck - you'll need it!
Contact info? (Score:1, Interesting)
Re:Success = sound business model (Score:4, Interesting)
Or, better yet, it could be something he could recruit other businesses into supporting with some cash, so that it increases the odds that he (and the others) will get a quality piece of software ("QPOS"), and that the coders will find a market for books (like "QPOS Unleashed in 24 Hours for Dummies: The Missing Bible in a Nutshell") and for support/customization contracts, thus possibly reducing their demands for cash.
Thread for those interested in participating (Score:2, Interesting)
Overall goal - Develop a system that can be deployed on as many existing POS machines (that are at least able to do general computations, i.e. not embedded POS only hardware) that uses a standard format for storing customer, transactional, etc, data. This would provide a strong foundation for sales-reporting, statistical, etc, use. A standard 'sales info' format would do a great deal of good when it comes to providing choices for POS solutions.
I'm a senior in computer science at the University of Tennessee at Knoxville. I have also thought that the current crop of POS software is shabby at best. Most of the POS systems already run on general purpose computers, so it would be ideal if it was possible to have a lightweight system to use this hardware. A complete system would be a distribution capable of running at a number of levels. Here's my idea of what the levels and their goals could be. Every level would be configured to be able to interoperate with other POS machines (both those from within the project and from outside, facilitated by a published communications protocol)
Very low resource POS terminal - This would be the mode intended for an ancient machine that still is able to run linux. It would be a console (text only) interface with the goal of a no-frills functional (but still easier on the eyes and easier to use than first generation POS consoles) POS machine that could be stand alone or networked.
Mid level graphical - A lower resource version of the next level, with some eye candy and other intensive features removed. Would most likely be the most commonly used.
Full performance graphical - Runs a graphical interface that takes advantage of all available resources. The overwhelming majority of PCs could support this.
Server station - May also act as a POS station. Coordinates the activities of any number (scalable to redundant multiple stations if there's need) of POS stations, coordinates the storing of POS data into databases, enforcing policy for POS stations, etc. A central point of control for monitoring real-time activity, controlling stations, etc.
Dumb frontend - A station that does not need to be directly connected to any hardware, but rather uses server-supplied resources. I.E. a dumb touchscreen could be a frontend, while the credit card reader and reciept printer connected to it are actually connected to the server, though this is transparent to the user.
Communications between devices can be secured via public key protocols: a key stored on the harddrive, or a smartcard stored inserted in a reader, possibly with the reader housed inside the PC case for tamper resisitance. Employee permissions could be controlled in any manner that PC security is handled: smart card, password (not recommended), biometric, etc.
Been there (Score:3, Interesting)
The cheapest proprietary solution they found for this was about $30,000. I think my time to implement the system and train the staff on it, at $15 an hour, was probably close to $1000.
Their next problem was their awful POS/accounting system. After talking extensively about either writing a new POS/accounting system, or hooking the inventory program into their current program in an automated way, we decided neither was worth it. Writing a POS that didn't suck would have taken months and extensive knowledge about accounting, tax law, and security. I also didn't want to be even remotely responsible for stolen credit card data, which would be a disaster.
Also, none of this is a fun or interesting problem, it's tedious in the extreme. You could probably pay someone like me to write a POS that is comprehensive, secure, and reliable, but I'd estimate the cost in the six-figures once all is said and done.
And that's why they cost $5000, because if you could write one (and support it!) in your spare time for cheaper than that, you'd only have to sell a few hundred copies at $1000 a pop to become quite wealthy. Someone would have done that already. It's not going to happen any time soon.
Re:Oppertunity Cost and Security (Score:3, Interesting)
I would bet a whole lot more. In fact I got a whole lot more when I designed a POS for a retail chain
Re:Success = Strong Leader + Initial Codebase (Score:3, Interesting)
"In terms of opportunity cost, you'll likely spend that same $2-5k making a custom solution."
The $2-$5k quote is the average per terminal that I kept getting back from requests, not including backoffice functions and other additions I needed. I have already purchased a closed source solution ($xxk+) since I don't feel like running alpha code in a business environment. However, I would like to mitigate these costs for new businesses to get set up and running similar to what Apache has done for web servers.
I would keep paid developers throughout the project and any support as needed. $2-5K is not the final amount I wanted to contribute, but just the beginning which is why I asked whether I should start from scratch vs seeding another GPL project. This isn't part of my business model or strategy. I am planning to create a separate 501c3 corporation to handle this and provide the majority of initial funding. 5-10 years out I would like to see it self supported through membership fees, tax-exempt donations, grants, or association supported, again similar to how Apache is set up.
I'm aware of the challenges of getting businesses to even consider GPL based solutions. I'm not looking to go after large scale POS solutions but would like to provide the foundation for stability, scalability, and cost efficient solution for the future.
Something along the lines of what I was thinking: http://ask.slashdot.org/comments.pl?sid=319387&threshold=1&commentsort=0&mode=thread&cid=20872645 [slashdot.org]
Shameless plug (Score:3, Interesting)
If you were instead to, say, join LedgerSMB, we could do the programming for you at a whole lot less that you would have starting the project yourself. You could help the project and we could help you too. If you have funds, pay for features you or your customers need. If not, you can still sell the software and leverage the larger community. But if you can't do the programming, you are going to get stuck really fast.
Re:Success = Strong Leader + Initial Codebase (Score:4, Interesting)
I started my business a few years before the fork, with the aim of helping businesses use open source software. We did a number of SQL-Ledger modifications and then the author of the software decided to see me as a burden instead of an opportunity. I ran into a lot of issues with being silently removed from the email list many times, and eventually mostly focused on attracting business through the wiki (I used to run the SQL-Ledger Wiki).
At one point, I was working on a customer's SQL-Ledger instance and I discovered a privelege escallation issue which I reported to the author and got no response. Six months later, the issue was still unfixed and so I did my digging an discovered it was no privelege escallation issue but really an authentication bypass problem. I argued with the author some more but let it go (as I felt like I didn't have the time or energy to run a fork).
Nearly a year after I brought the issue to the author's attention, I finally realized I had to fork because it wasn't going to get fixed. Josh Berkus introduced me to CHristopher Murtagh and the project was born. LedgerSMB was a fork which was mostly mandated by a requirement that I help support my customers, not a hobby project or anything like it. Now we have 3 additional people on the core team, and have released more than 15 releases in the last year, and our userbase is growing by leaps and bounds.
In general, I would suggest that the key issue has to do with having software which is either interesting to geeks or needed by consultants, and it is critical that one build the community around the software.
Re:Success = sound business model (Score:3, Interesting)
I think this is also a good model for governments and educational institutions. Basically, any time you have a lot of organizations with nearly identical data processing needs, it would be in their best interests to fund an open source project to develop the software they need.
It would be really great if this kind of model caught on and created a substantial market for open source programmers.
Re:Success = Strong Leader + Initial Codebase (Score:5, Interesting)
I worked on a new POS for a fortune 500. There were a ton of requirements both from our side (programmers) and the hardware side (admins). It was actually one of the coolest projects I worked on in the last 10 years.
I got to really understand the needs of the admins as a programmer, and they got to see the reality of software systems. We (programmers) made compromises and they (admins) made compromises in the system.
The "simple" POS had to be fault tolerant. If if could not send back a transaction to a master server, it had to store it. One it could talk to the master again, it could send the transaction. This had to be done across a few thousand locations. The systems needed to be self "healing" (manager speak), we made them self updating by asking a master update server over frame relay for a version, get back an XML file and self-update from there.
There were a sh!t load of other requirements we had to handle on the software side like SOX, etc. The final POS was anything but simple. Oh, and the admins has a crap load of work to do as well. Those guys worked their @sses off to get each location secure and plugged in to our AD server, our Netegrity server, etc. Our software or POS system handled the AD and Netegrity communications, but there was a lot more for the admins to do then it seemed at first.
So, yeah, I think most programmers and admins would find implementing a real POS systems a good challenge. I know I did.
Re:$2000 to $5000 isn't expensive enough? (Score:2, Interesting)