Slashdot Mirror
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?
First off, you really need to check SourceForge.net or FreshMeat.net first. There there are plenty of POS software projects listed at both. Find one that looks like what you're wanting to do and hasn't run out of steam, and give it a shot in the arm with some cash. Maybe spread your cash around two or three of them.
That said, the question of how you start and attract talent to an open source project... I'm not professor on the history of open source, but the most successful projects I've seen are ones where a coder or small group of coders put out an alpha of their project and it was playing with the alpha and seeing the possibilities in it that got people excited enough to come on board and start pushing things forward.
So, if you're not happy with any of the POS projects you can find on SourceForge or FreshMeat, and since you clami to know "little to nothing about programming," I'd suggest going over to eLance or RentACoder and spend a good chunk of your seed money on getting an offshore firm to build your alpha for you. While they're coding their hearts out for you (they'll want 2-3 months to work on your contract), take that time to get to know the open source community and how people launch their open source projects.
Then, when your offshore coders come back to you with a decent alpha, pick an open source license (BSD, GPL v2, GPL v3, etc.), and use the knowledge you've picked up in the prior few months to get the word out and spread the code around. If you did your homweork well and spread the word well, that seed you planted may well sprout.
But remember this, a strong open source project needs a strong leader who can handle the big picture outlook, keep all the volunteers in line and focused on the goal, and drive the project forward. You're going to have to approach some strong personalities one-on-one and try to recruit that project leader. Without a strong leader, failure is a definite possibility.
Just my $0.02.
- Greg
Start a happiness pandemic
Have you seen their products?
http://www.linuxcanada.com/pos.shtml
I am not affiliated, just been aware of them for 3-4 years now.
Windows is not the answer.
Windows is the question.
The answer is "NO."
If you want to get an open source POS package, I think the most important thing to keep in mind is support. When the package breaks, are you going to be able to contact the coders for help? (Sure, it should be written to never break, but let's be realistic.) You may know enough to fix it, but what about your employees? They won't necessarily be able to get you on the phone when they need to. I used to work for a company that produced a mediocre POS package, and the amount of support calls we used to receive was insane. Everything from hardware, software, training questions, networking....we had it all. Point is, make sure that you have someone waiting on the phone for you when stuff happens.
If you post as Anonymous Coward, don't expect a reply.
I totally agree with the parent.
I'm talking from a first hand experience, since I've been working on a Java POS solution for past 18 months. I'm a part of a new team of 6 developers dedicated to this project. The company has been (continuously and successfully) in PC POS business for the past 15 years. We are replacing their legacy DOS application. Here are some lesson we learned (some are POS specific, some are valid for enterprise SW development in general):
1. We couldn't have done it, if the company didn't already have extensive experience in this market. Programming experience is not enough, one has to know the market and customer expectations. PC POS is a tough market with a lot of competition that has been around for ages (lately including Microsoft). You can not get by with an amateur product.
2. Forget about the low-end off-the-shelf PC hardware. POS needs reliability (every hour of down-time means real money lost + getting a bad name with customers). Go for all-in-one specialized POS systems. They start at about $1500 (+options).
3. POS market needs support, even if some inexperienced first-time merchants think otherwise. Prepare some support plans and people to do it.
4. Store owners/managers put A LOT of emphasis on controlling their own staff. All serious POS systems are concurrent multi-user enabled (multiple users logged-in to application at the same time with fast GUI switching). RFID dongle for every user is what really works in the end.
5. You will not be able to customize the application for every small customer and their POS process. A lot of times you will have to teach them best POS practices and have this supported in the application. However you will have to bow to the bigger customers and customize the application for them. Result: you will end up with a lot of different sub-versions of the application. Bug-fixing and upgrade process is going to be a pain. Plan for it before all this starts.
6. Sales people will always sell features that are not there yet or are impossible to produce (due to technical or cost constraint). Train sales people to check with you first.
7. Have people that are not developers test the application before release. Testing your own code virtually means nothing. Once you release it to the customers you'll be amazed at how many bugs they can discover. As if all the unit testing and hand testing was in vain (it is not, continue with unit testing etc)
8. Write comments and API documentation (javadoc or equivalent). I REALLY MEAN IT. I often find myself wondering what a piece of code is doing, just to discover that I wrote it 6 months ago.
9. Do not write UML or any other developer documentation that is outside of code. It's just additional work that is always out of sync with code. And it only makes PHBs happy. Only exception to this rule is a short architecture overview of max 10 pages - this will save your time when new developers arrive on the project.
10. Choose a good IDE and be willing to pay money for it. Good IDE is much more important than a good car! Some developers I know are you willing to spend obscene amounts on a car but nothing on an IDE. You can always get a cab if your car lets you down, but IDE.. Again - this is no place to save money.
11. You should already know this: you need a versioning control system and a continuous integration system. Go with open source ones - they just work.
12. Automatic update system for your application is A GOOD THING. Selective (forceable, with consent) update per customer is even better. Try to stage updates - update first customers that are close to you (in miles and mentality). If all works well, roll out to everybody.
13. In case of troubleshooting a remote connection (VPN, RD, SSH, whatever..) to customers computer is worth a lot. Try to plan this upfront.
That's about it. Good luck writing your own POS application, just to save $2k.
And next time you need a new car, just build one.