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?

Linux Cananda has a Linux GPL (and commercial) POS

[waa]

Have you seen their products?

http://www.linuxcanada.com/pos.shtml [linuxcanada.com]

I am not affiliated, just been aware of them for 3-4 years now.

POS for coops, but it is a good start

[Anonymous Coward]

http://www.wedge.coop/is4c/ [wedge.coop]

Re-inventing the wheel

[Chandon Seldon]

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 [freshmeat.net]

Customisation

[Spy der Mann]

At the risk of sounding too obvious, here's my advise: If you want to earn money with open source, charge for the customisation and maintenance of the software, not for the software itself. This way you can pick up whatever open source project you decide, since you're adapting it for your customer.

Re:Success = Strong Leader + Initial Codebase

[gdek]

Yep.

Not only that, but your chances of success go up markedly if your codebase is (a) functionally complete enough to be immediately useful to many users *very* early on, and (b) highly modular, so that where a feature *isn't* available, it's worth more to the potential developer to write a new module for your codebase, rather than to start a codebase of their own.

There's a great Harvard Business School [hbs.edu] paper on this topic. Game theory and all. A mathematical proof about why projects like Drupal expand dramatically, and why projects like OpenOffice rot. :)

--a different Greg

Realistically...

[C10H14N2]

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

renta-coder too.

[www.sorehands.com]

My experience with an offshore project didn't give me a warm and fuzzy feeling. Despite several e-mails where I even wrote pseudo code to explain the algorithm for audio gain scaling, they still didn't understand. I just wrote the code and e-mailed them the code.

The issue with spaghetti may also occur with RentACoder. Spaghetti code is not just an offshore option.

You get today's creative context stripping award.

[mr_mischief]

He said he wants to pay someone to do the programming because he knows about point-of-sale systems and not about programming. He's what some software teams call the "domain knowledge contact", or what a freelance programmer would call a "client". Outside of "scratch my itch" projects, a lead programmer is rarely the domain expert on a project, and the domain expert on the project is rarely a programmer. That's what interface specifications and client use scenarios are for.

If you're having issues with the concept, pick up a book or a short net article on Extreme Programming. While reading it, note how much time the authors spend explaining how to communicate what's desired by the customer to the programmers and what's feasible in the budget and time constraints from the programmers to the client. XP is not the only methodology out there that addresses this, but it addresses it clearly, voluminously, and in recent, easily located resources.

Re:Success = Strong Leader + Initial Codebase

[Anonymous Coward]

Yup. The biggest problem is however getting working hardware drivers for the equipment like barcode readers, etc. They do not necessarily come as a generic device -- even though my UPS is driven using usbhid.ko (an UPS is a HID?), I suppose you'd still need some specs to interpret that data.

Ready To Start

[kurtb149]

I have developed a relatively successful, proprietary restaurant POS, based on an all open-source software stack. If someone had funds to support a very small team of developers for one year, I could create an entirely open-source version (complete rewrite, of course). The POS application suite is a large, complicated, and feature hungry piece of software and should not be thought of as anything less. Money is made with the software by running the main repository and configuration interface as an ASP service and charging a monthly fee to run the software there and in the stores. Something like 40 - 200 USD per month per store depending on what extras they want.

Re:$2000 to $5000 isn't expensive enough?

[pooslinger]

I planned to just have POS functions at first. Scan/input items, calculate total and tax, eject cash drawer, save/update sales records. I would want the businesses using this system to be able to have sales reports/data in the most open format so the can import that information into what ever accounting software they used.

In the future I would like to add backoffice functions like accounting but keep everything as module as I can. If people want to use Quickbooks they have that option. However I would like to try to have the POS interface with as many GPL applications as I could to mitigate costs for small business.

Join LedgerSMB

[einhverfr]

Please join the LedgerSMB project. Our POS solution at the moment works for retail environments, but there an understanding that we need to build an alternate interface for it. You could be a part of that and enter into a project where there is already a lot of (paid) work and where a lot of the code is in place to do what you want it to do.

LedgerSMB is a full accounting solution. A POS component would merely interface with core accounting logic. It is not a lot of code and could be managed with Perl/Tk, Perl/GTK, or (as we begin seriously on 1.4) any other framework you like as the core accounting data is moving into the database. In six months, hopefully you can have a product that would take yourself years to build, and you can be selling your services for good rates.

As I mentioned, there is a lot of demand for LedgerSMB consultants, and this is expected to go through the roof as get a better POS framework in place. Most of the core team is saturated with work on this project (most of it paid), and so it is an opportunity for others as well.

Best Wishes,
Chris Travers

Re:Customisation

[pooslinger]

I am not looking to earn money from this or open source. This would be a separate 501c3 foundation like Apache. This corporation would be completely separate and autonomous from my business except for the funding.

People always underestimate how much

[einhverfr]

a POS framework needs to do.

I have customers running LedgerSMB in a POS environment. It doesn't handle all environments at the moment (mostly just for retail), but it does work.

In general, you are talking about a system which generates invoices, collects and tracks money coming in and out, etc. Sounds almost like a full accounting system (which is in fact what LedgerSMB is). LedgerSMB is under the GPL v2 or later (no plans at all for moving to the GPL v3).

We inherited a mess of a codebase though and are working on it as quickly as we can. And we welcome contributions (and are willing to share the workload in terms of paid work too).

$2000 will buy you

[einhverfr]

the *hardware* for a POS terminal. We haven't even got to software yet.

This is an expensive area. And it is one where timely support is absolutely critical, as is database performance, and the like.

Re:Realistically...

[peti]

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.

Re:Don't be an Idiot

[pooslinger]

I am not an idiot and have already purchased a closed source solution. People are reading in to that my business plan is to wait for my POS to come to fruition. I am merely trying to minimize this expense for other new businesses and provide a clear, focused effort. This would be a separate, autonomous nonprofit entity.

Re:$2000 to $5000 isn't expensive enough?

[d3matt]

Hey pooslinger... I would be willing to give some help to this as well. I do free tech support for a lady who runs a dry cleaners and would love to give her a better POS system. Right now all she has is a cheapo cash register and then she enters stuff into quickbooks manually. Shoot me an email and we'll talk some more. (my slashdot username at hotmail.com) Matt

Re:Realistically...

[C10H14N2]

I have to disagree with one point...the UML bit (I know, I know, groan). IF someone is crazy enough to blithely jump into something like this and has no relevant programming experience and will have to fork out major money for someone who does, planning out on paper in minute detail everything they think they need, even if it's just a couple use-cases and bunch of simple flowcharts and sequence diagrams, will serve to indicate roughly how far over their head they've just gotten themselves. Frankly, one weekend of that tedious bullshit might be sufficient to derail a potential nightmare before it begins.

I agree, though, once you start actual work, avoid at all costs revisiting said tedious bullshit until you're at the point where /customers/ need some form of it...and even then, keep it at the big-red-crayon level.

Re:PCI-DSS / PA-DSS

[mrericn]

+1 I'm in the EFT field as well, and while it sounds like a fairly simple project, you are in way over your head. It's almost like building a kit car instead of buying a Kia to save money. But there's no kit. And even if you build it, you have to deal with the DMV, except instead of one bureaucratic institution it's a mile long list of processors, credit card companies, and banks who are much much worse.

Now if you said ... "I build and sell closed POS platforms for a living and I want to build and sell a GPL POS platform." You might be in a position where that could happen. Heck I might even help.

Re:Not sure I understand.

[Daengbo]

He should talk to the guys over at LTSP [ltsp.org]. They've been doing POS setups for probably eight years now, using thin clients. Local printers. Local barcode readers. The software. They've got it all.

Take some old, small form factor PIIs and any modern server and you're in.

Re:$2000 to $5000 isn't expensive enough?

[aevans]

I'm interested too. Getting the hardware interface working is the trick. Barcode scanners are easy enough, but touchscreens might be trickier. And then drivers for the receipt printer and cash drawer and credit card readers.

So I see three systems:

1. The POS application. That's fairly straightforward. Creating it modularly and fulfilling tax and accounting requirements are the difficult part, but really just about finding the right regulations and other documents.

2. The drivers for all the POS hardware. Probably a base Linux OS (pick your flavor) frozen and tested with identified drivers for specific hardware. I'd start small and just get what you intend to use. The value add will be in adding support for new hardware and this will be a good area for (paid) community involvement.

3. A framework for integration with back end inventory, accounting, and payroll/timesheet applications. This would be where bespoke customization could pay off.

Like I said, I'm interested, willing to learn existing POS and integration apps, but not really expert at writing drivers. My email is ahdevans atgmail.com