Slashdot Mirror

← Back to Stories (view on slashdot.org)

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

Posted by ScuttleMonkey on from the will-food-for-code dept.

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?

4 of 231 comments (clear)

  1. Linux Cananda has a Linux GPL (and commercial) POS by waa · · Score: 5, Informative

    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."
  2. Re-inventing the wheel by Chandon+Seldon · · Score: 4, Informative

    You probably are re-inventing the wheel.

    There are a number of existing free software POS apps. I'd suggest going through the list with a fine tooth comb and making sure that none of them even comes close to meeting your needs before trying to start a new project.

    http://freshmeat.net/search/?q=point+of+sale&section=projects&Go.x=0&Go.y=0

    --
    -- The act of censorship is always worse than whatever is being censored. Always.
  3. Realistically... by C10H14N2 · · Score: 4, Informative

    1) You can get a very nice shrink-wrapped POS system, including hardware, for a lot less than $5k.
    2) You will not be able to develop even a very crappy POS system from scratch, sans hardware, for $5k--even at Bangalore rates.
    3) While you develop a going-to-be-crap-for-a-long-time POS system, you need a reliable one to run your business.
    4) Many software development projects die unceremonious yet expensive deaths.
    5) This may be nothing but a colossal waste of time and money.

    Because of all of the above, if you really are peeved to the point of diving into building something from scratch, you're going to need to know /something/ about programming, even if you eventually hire someone else to do it. Research the existing commercial offerings and open source offerings. Find one of each that you think works for you. BUY the one to run your business now, TRY the open source one in your own time, then learn enough about the language behind the open source one to modify it for your needs. After you've got enough chops to tweak around the open source project, then start thinking about branching or starting your own, with or without the aid of hired guns. Chances are, by the end of this, you'll find that:

    1) The commercial product is sufficient
    2) The cost-benefit exchange makes rolling your own FAR from cost-effective
    3) You're not a software company
    4) The time and money it would take to become one is enormous and way too risky
    5) You have better things to do with your time and money anyway

    1. Re:Realistically... by peti · · Score: 5, Informative

      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.