My main project is an award winning, public domain / free/libre refugee shelter system called the hexayurt.
So, I've got a technology that I'm looking to get turned into a product. For ethical reasons there will be no patents or IP protection - you could write a closed implementation, patent additional side features etc - but the basic ideas are already disclosed. The cat is out of the bag, because this is refugee stuff which just happens to have some other applications, and so I disclosed it to make sure it would not be patentable from my work. There may be other patent issues, although none have arisen so far - we have yet to hit prior art.
Technologies: mobile phone programming, 2D bar codes, very large databases, and some basic understanding of cryptosystems. Like, how to call the libraries, not how to roll your own broken encryption.
Now, here's the kicker: if I'm not entirely mistaken, I have a customer lined up. A Large Customer. If that turns out not to be true, there's no point starting this thing.
If, however, it is, the gig would start with one large contract, and then if you can then make this into a company, you go right ahead. I'm fully engaged pushing the Hexayurt Shelter System (a free/libre refugee infrastructure system) and don't have time to do a start up. I can advise, and make the introductions. From there in it would be up to you to make it a success, working with that client. My compensation is likely to be largely as a subcontractor to that client, working on the design end.
Interested? hexayurt@gmail.com
Ideally, this would work on any old phone. Realistically, this would be vertically integrated - you'd get to pick the phone, and the printing format for the page containing the data. From the specs and the initial discussions I've had with companies in the field, the speed of light for 2D bar codes is about 3mb per page (Data Matrix) and the choke point is mobile phone camera quality, particularly focal length issues (can't focus properly on the close page.)
Approaches: using better phones, deconvolution algorithms, c'mon guys, you know how to fix this.
After that, there's some extremely simple large scale database stuff which looks, to my eye at least, to be a natural fit for REST.
Basically:
Yank data off the page
think about it
do stuff over GPRS/3G or - ugh - SMS (yeah... SMS out, SMS back... terse data formats.)
Done.
Nothing about this is difficult. The crypto fits in just to ensure data integrity - make sure that the bar codes haven't been damaged, or that the data on the bar codes isn't stale.
Ok? Enough here to be going on with? Do we need to belabor the point further? For the right team, assuming the deal comes through, this would be an easy gig.
If it doesn't, there's no gig, no client, no business, even if I disclosed the rest of the pieces here. So it's a potential and there's not much you can do to make it happen or not. But if it does come through, first plausible team might make a pretty good living for a few months and possibly be left with a viable company at the end of it. Can't promise more than that. In terms of IP, there would be full disclosure, no NDAs, no patents on my work as I described. There could be competition, although probably not, and for other reasons I'm not simply posting the whole damn design on the internet (more on that angle later.)
Ok, done. Nothing more I can think of to tell you, please ask more questions either here or by email.
Vinay