That reminds me of something I read once on Apple's website one day, that seemed to suggest Apple invented CUPS in 1997. They hired the developer and bought the rights in 2007, so it's fair to say it's theirs, but it was worded as if this was always so.
Major congratulations to him! What an achievement!
I wonder though: in these situations if he were to refuse the acquisition would Apple just steal his idea (NOT implementation) and bake it into the iPhone regardless? I think Microsoft did something like this, no? Any thoughts?
The article states "I’m not naive enough to claim Apple actually took my idea." You apparently are, though.
> Apple rips off student's rejected iPhone app - iOS 5 lifts idea, name, even logo
C'mon. "Wi-Fi Sync" is hardly a surprising name for such a feature, and making its logo the bog-standard Wifi logo with a bog-standard Sync logo superimposed is hardly a surprising choice either. It was a long-expected and long-awaited feature.
> Konfabulator, Dashboard controversy flows out of WWDC
A controversy about the bog-standard term "widget".
> Apple stole Karelia Watson
Well, it made its own version and named it cheekily. This seems to be the one mostly valid case in your post.
It was a different time when the images/weather app was rejected by Apple. They were deliberately trying to prevent people creating thin wrappers around websites and calling it an app. And at the start it made a lot of sense.
Syncing over WiFi was a feature that users had demanded long before that app had been around and the name/logo are not distinctive. They are the most common sense choices you would use.
And widgets existed decades before Konfabulator thought to bring them to OSX. They were available as Desk Accessories in the previous versions of Mac OS as well as on Windows/Linux.
Also, re: the shock of someone lifting the icon of the wifi sync thing. If I am an Apple designer, the first idea for a wifi sync icon will be combining the wifi icon with the sync icon. The most obvious way to do that is to put the sync icon (two circular arrows) around the wifi icon.
It's pretty clear this was just two people coming up with the same logical icon concept simultaneously.
Instapaper was an idea, and Marco is pretty firmly in the camp that you can't steal "ideas" (Though, you can do feature-by-feature clones, which another of his competitors did in a really annoying fashion. )
Yes, and he has discussed his fear on the launch of Read it Later, but the non effect (it was it a slight bump?) on his sales. To me however, that is a courteous approach. Apple saw and copied with a better implementation that 3rd parties couldn't copy.
I don't think that this is something he would need to worry about. Implementing complex algorithms is extremely difficult, even if you have detailed instructions (eg. from a published paper). I've read his website before and if I remember, he only published high level details. To steal his ideas, you'd need to have a similar background, and you'd need to know just as much about compression etc. as he does. And even if you found someone with the right expertise, it would still take a very long time to "steal" an idea like this.
When you're coming up with a new idea, you often have to go down a bunch of dead-end alleys and you're not even sure if what you're attempting is possible. When you're reimplementing an existing product you know exactly the right avenue to go down, and you know for sure it's possible.
And Apple has over a hundred billion dollars in cash and eighty thousand employees. They could certainly clone this software if they wanted to.
The reason to acquire is to signal to other people that doing innovative things on apple platforms can make you a millionaire, instead of signalling the same thing is a sucker's game as apple will steal your ideas if they're any good.
"you often have to go down a bunch of dead-end alleys and you're not even sure if what you're attempting is possible."
This is my biggest worry with my product. I literally spent two years going down dead-end alleys to refine my Information Flow Control System because there was nobody that I could copy from. We often hear "Ideas are worthless. It's the execution that matters." which is true but knowing what does and doesn't work is as important in my opinion.
Apple now knows you can capture video very efficiently with JPEG. People now know, if you want to build a powerful social media product, you'll have to use real names and so forth.
I can't back this up with citations as I don't remember where I read this from, but it basically said innovators are usually not the ones that benefits from their innovations. It's usually those that tweaks the innovations that benefit the most.
I guess the message is, if you do have something innovative, you should probably patent it. You might not be able to protect yourself from larger companies, but you'll certainly improve your chances of being acquired.
You do realize the enormous technical accomplishment that Snappycam's reworking of the jpg algorithm, and it's implementation on the iPhone processor was, right?
To call it a "decent iPhone app" somewhat puts down the 12 or so months of hard core research and implementation that jpap put into it.
As far as I can tell, Apple's acquisitions are fairly standard build-vs-buy decisions. Lala had the infrastructure for what became iTunes Match and the price was right, so they bought them. Siri was a fairly complete piece of technology that solved some hard technical problems, so they bought them. Konfabulator was a technically trivial application that Apple wanted to rewrite in a totally different way, so they built Dashboard.
>>would Apple just steal his idea (NOT implementation)
I think the App was more about the implementation than the idea. He created extremely efficient implementation of jpeg compression with 50000 lines of C++ code as far as I remember from the dev's blog. So Apple is obviously more interested in the guy than anything else.
Yeah, but that's a slightly different scenario – they a lot of developers on staff already know how to implement private message functionality, and they have better expertise on staff than SnapChat do for the difficult part - getting the UX right.
Here, just one guy was doing this a very sophisticated thing that was clearly out of the reach of Apple's developers (SnappyCam came out long before iOS 7, but the new in-house iPhone burst functionality doesn't work half as well as SnappyCam's).
Apple has earlier ripped off the Swiss Railway watch face, and also pilfered the idea of using volume button as a shutter for the camera. They apologized for the watch face, IIRC.
When I first heard about the SnappyCam that is capable of taking blazing fast photos using a regular photo cam, I immediately purchased a copy and experimented with it. Not only it doesn't everything it claims (essentially a breakthrough in super optimized image compression) but also the UI is well thought. At the time, I was certain that it's just a matter of time to get Apple's attention and very likely Apple would want to acquire the technology. Kudo to Papandriopoulos (How do you exactly pronounce that??)
What I'd like to add that, it apparently SnappyCam would only make sense on iPhone 5 or lower. That is because iPhone 5S already can do what SnappyCam does in its native Cam app by holding down the shoot button. Perhaps Apple got other ideas for its use in the future.
I think you may want to do a wee bit of editing, because I assume you meant:
"Not only it doesn't everything it claims" -> "Not only does it do everything it claims"
"but also the UI is well thought" -> "but also the UI is well thought out"
The actual standard allows for a variety of options around how the compression portion is handled -- there is the baseline mode and then options for custom huffman tables, etc. The best source for the JPEG Standard --
My memory is a bit fuzzy here, but from what I recall, a friend tried implementing JPEG compression on a parallel system (back in the mid 90s). One of the trouble spots was the reliance on the relationship between blocks regarding prediction of the DC coefficient.
One startup I worked at, we had an entropy encoding method that could add 20-30% additional compression just by recording coefficients. Patent here -- http://www.google.com/patents/US6236762
It sounds like he didn't optimize the algorithm per se; he optimized the implementation of the algorithm for the particular processor. Still very impressive.
"Having developed a blazing fast DCT implementation, Huffman then became a bottleneck. We innovated on that portion with tight hand-tuned assembly code that leverages special features of the ARM processor instruction set to make it as fast as possible.”
I understood he first optimized the algorithm, then tuned it to be even faster on ARM?
I read it as saying that, after optimizing the DCT (lossy) compression as much as he could, he focused on the Huffman (lossless) encoding phase which gave him further optimization opportunities.
I was amazed the first several times I saw things i thought where old as dirt have amazing improvements made. One of the first was about 10 years ago, when a friend made improvements on lighting ballasts in conjunction with solar work. Now I try to keep my eyes open for these opportunities.
I'm not so sure about it, but lossy compression algorithms are usually "non deterministic" and what I mean by that is that there is a target format to encode to, but you have some variation in how you're turning the original data into that
So there's a lot of room in optimising the process
Aussie Aussie Aussie, Oi Oi Oi!!! Congrats to John Papandriopoulos! Very impressive work.. also the amount of work that went into it is wow!! .. "The final implementation comprises nearly 10,000 lines of hand-tuned assembly code, and over 20,000 lines of low-level C code. (In comparison, the SnappyCam app comprises almost 50,000 lines of Objective C code.)"
Good for him! The app is a bit of technical marvel. I love playing with it, and now that Apple has it, hopefully the UX will improve a bit in whatever way they decide to implement the core tech. Wins all around!
I am confused. Is it that the transfer speed was limited by the compression algorithm rather than the speed at which the images can be retrieved from the photo sensor array? I had assumed it is the latter.
If we can believe that jpap told us the entire story, It's the former. He never mentioned modifying, in any way, the mechanism by which images were retrieved from the photo sensor array, just how he compressed and saved them.
Since Apple already has this as an advertised feature in the 5S, I see this as one part acquihire, one part locking up tech so it can't be used on other platforms.
Why is a buyout like this reason for celebration and congratulations? I understand that the developers received money; but now they no longer own their IP, and can no longer decide the future path for their software.
I say this as someone who was contacted by a VC firm recently. They were interested in investing, but their assumption was that we wanted to grow and "exit". When I asked for clarification on what "exit" meant, I was told that it means to sell the company. I was confused as to why someone would want to sell something they spent so many years creating.
(That said, I think in this case their tech will genuinely improve Apple's software. And maybe they get to continue doing passionate work at Apple. It just feels like they are no longer in control.)
I guess so, it's just that his direction under Apple will not be his own. Perhaps he will be allowed to work on whatever he wants, even if it's risky or experimental?
If that was part of the nature of the deal, then I could see it being quite attractive.
It might be a bad assumption on my part. I have no idea what it's like to work at Apple. Perhaps all employees are allowed to work on whatever they want, and pursue their personal passions.
No doubt Apple put a very lucrative offer on the table, but another route could have been for the author to dual-license the code - GPL it so the community benefits, while any improvements he can then push out in his app which he continues to sell.
My guess is that Apple values his underlying algorithm implementation, not his app. The implementation seems highly architecture specific and tuned for certain ARM processors.
It seems like Apple might replace their iOS JPEG implementation with his, and all developers on iOS will benefit from the very fast image encoding routines.
I wonder how this ties into Apple's other recent acquisitions - if I remember correctly, they recently purchased a company that was mounting depth sensors on iPads. Fast image processing is central to usable 3d augmented reality interfaces, and Apple might be planning ahead for 2015's iOS innovations.
That guys work is amazing. I saw snappycam before and didn't bother downloading it or looking into it. Now I'm reading up about it and it seems absolutely amazing. I can't wait to see how this technology is implemented in future iPhones.
Cool, hopefully they open source this code sooner rather than later. Obviously they are probably going to keep it as a competitive advantage for the next batch of iOS devices but I hope they open it up shortly after that.
If Facebook acquired this then the technology would be accessible to a far greater audience than just the users of Apple products.
Seems to me that we should want advances in technology (software or hardware) to benefit the greatest number of users possible, and with Apple owning this it now restricts this method to only those who use Apple products.
Oh, just noticed your username.
Edit: Being downvoted? Do I have to do the defensive thing of pointing out I own Apple products too?
If Facebook acquired this then the technology would be accessible to a far greater audience than just the users of Apple products.
I'm unclear why we are arguing whether this technology is somehow better off in the hands of one monopolistic, predatory giant instead of the other monopolistic, predatory giant.
The way to make this technology truly accessible to a far greater audience is to make it open. Everything else is quibbling over which King has the softer boot on the neck :-)
In the previous post about SnappyLabs the author said he wasn't looking at doing an android version at the moment, and gave the impression that there were technical reasons why it was more difficult.
You seem to imply that this kind of performance tuning would carry over to Android, via a Java/NDK bridge? I sincerely doubt that this would yield results as good as SnappyCam.
Why? The app's been discontinued, and based on previous Apple acquisitions the integrated version will probably only be available for the iPhone 6 even if there's no technical reason to limit it in that way.
Great for the guy, but this screws customers of his app. SnappyCam made animated GIFs of your snaps. I highly doubt Apple's native camera app will ever do that. Now that the app is gone, this royally sucks and is a fat middle finger to IMGUR and Reddit's communities that produced animated GIFs using SnappyCam.
https://web.archive.org/web/20131010012005/http://www.snappy...
I wonder why they took it down.