What is the Best Way to Start a Paid GPL Project?

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?

Comments

PCI-DSS / PA-DSS

[MtlDty]

You've jumped on the bandwagon at just the wrong time. The EFT industry (which I'm part of) is currently going through a bit of an upheaval to increase security of card number data. If you're seriously thinking about devloping a POS solution, then I would take a long hard look at the number of hoops you need to jump through to become compliant.
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! :)

Re:Success = sound business model

[kylben]

Of course, supporting the software might turn into a secondary revenue stream, or it might be the kernel of a start-up for someone else.

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.

Re:Success = Strong Leader + Initial Codebase

[pooslinger]

The title sounds like I want to just do this to save on my own costs, which is not true.

"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

Re:Success = Strong Leader + Initial Codebase

[einhverfr]

I would suggest that a good counterexample is LedgerSMB.

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 = Strong Leader + Initial Codebase

[JimDaGeek]

I see you posted as an AC. A POS is anything _but_ mundane.

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.