An unofficial blog that tracked Google products and features, from Gmail and Reader to Chrome and Picasa, for many years.
HN links it as a historical record of Google's past, such as Reader subscriber estimates, discontinued Picasa Hello, and a domain-blocking search option.
To address your comment, I respectfully disagree with the majority of it. Especially "attacking you personally" I didn't do that as highlighted by the fact that I clearly stated "this may come across as harsh but, it's useful feedback"
Moreover, your comment came across (alongside this response) that Google "stole" your idea after you reached out to Google Ventures. The idea has been around for a while for instance, Virtual Video Map launched in 2006 (their domain is a parked page) which used Google Maps + YouTube - http://googlesystem.blogspot.co.uk/2006/06/google-maps-youtube-video-map.html - and that is something you should probably look at using their maps product instead of Google Earth would remove user friction considerably.
Similarly, the idea of a mole does ruin YC's credibility and it does not benefit YC - they are producing 2 Demo Day's per year who they have told the press and other investors that this batch of founders are ones who they believed are the most resourceful with potentially great ideas. Having a mole company goes against that ideology because, YC does not believe that this "mole" company is what they are saying but more importantly, YC are a company and they don't owe anyone anything trying to prove a point which is true.
Founders do have more power today - the cost of starting up a company has fallen drastically and more investors have realised that whilst they can provide help/ideas they have also realised/accepted that a founder may have more…
First, I love reMail. Gabor breathes email and search. If you own an iPhone and use Gmail or Google Apps, get reMail--you'll thank him.
That said, it's easy to skim this article and nod, "Yeah! Yeah!", but when we're discussing these, laymen may need to know a few of these seem over-simplified.
> "TCP connections are great, but for transferring large amounts of email securely, HTTP is the way to go."
1. http://wiki.answers.com/Q/What_is_the_difference_between_tcp_and_http - HTTP uses a TCP connection. For that matter so does SMTP and IMAP and the proposed REMAP.
2. I generally have at least 5 devices using IMAP (on Google Apps) at once, and interleave my interactions with these devices arbitrarily, yet expect each to show me the exact same state when I look at it. Keeping them all in the apparently same state is the sort of intractable software problem bedeviled with implementation details, and I agree throwing out IMAP and starting over with lessons learned could be easier than, say, the RFC linked below.
3. http://ajaxian.com/archives/json-vs-xml-the-debate - Seems this point is something like GIF vs JPG vs PNG, with a bit of "Markdown vs HTML" thrown in. Meanwhile, both XML and JSON are missing an important concept given labels/folders and conversations: multiple references to single objects.
4. Conversations or threads exist today as In-Reply-To: GUID and References: GUID headers, among others, but see the JSON problem above. We don't realize these headers are…
I worked at Google during that period. It's not quite as simple as "Python > C++" although yes, for sure, you're going to produce new UI features at a far faster rate working in a high level language like Python than working with C++. Absolutely that was a factor. I don't think Google Video had hundreds of developers vs 20 though. That doesn't sound right to me.
The real reasons YouTube won were strategic, not purely a function of developer speed.
In particular YouTube focused a lot on social / discovery features and prioritised them, at a time when the importance of social wasn't so obvious and Google in particular was very bad at anything with a social dimension. So Google Video had super scalable backends, great search etc, but it wasn't very good at user profiles, commenting, channels, subscribers, discovery, content surfacing and so on. Whereas YouTube excelled at these things and was good at encouraging people to upload whatever random vids they created even if apparently worthless.
Google in contrast was less certain that free user generated content would ever be a big deal, and right from day one saw Google Video primarily as a marketplace. It focused much more on acquiring content rights from professional producers as a result. Even YouTube wasn't really sure UGC+ads was going to turn into a real business which is why they had a lax approach to video piracy for so long. Early YouTube traffic was to some extent driven by piracy of professional content, a problem…
I believe you!
I think the problem I had was the piece read to me like it was arguing an equivalence not analogy.
>We build actual ontologies. Our system is an actual abstraction on top the data.
Pretty much all software does this. Perhaps implicitly, but it all does on some level. For example, edlin uses an ontology composed of concepts like a byte, a file, a line, a file handle, standard i/o, character codes to characters, etc. It abstracts the data from a bit stream into characters and characters into a line and lines into files, etc. Is edlin an "operating system" for editing files? I don't think anybody would argue that was case.
The same with Palantir, it's a software application (or set of applications) that succeeds in using an ontology for object and relationship semantics, it abstracts away the data handling drudgery, and automates lots of the search and correlation work. But make no mistake, it's an application.
The analogy I'd draw would be to claims of Google building a web OS (discounting Chrome OS which is still vaporware). http://googlesystem.blogspot.com/ Google is building a lot of interesting and useful apps, but the apps taken together != an Operating system. In this case "Operating System" has become an unfortunate buzzword.
Palantir is a particularly interesting application, full of interesting and compelling capabilities, but Palantir's code does not sit in BIOS at the CPUs entry point memory address, booting up upon power-on. It's not handling…
No I wouldn't.
1) Because there are so many free providers out there.
2) If the free providers don't find something, I don't know what I'm missing out on, so there is no incentive to pay. If I know that I'm missing out on something I probably have enough information to know how to find it without paying anyway.
What you are doing is asking people to pay for you to help them find something when as far as they can tell they have already found it. You can't demonstrate what value you provide to the buyer without giving all that value away.
All that said, I don't think that makes it a bad idea, just not one that you can charge the user for. If you build a system where user feedback effects search rankings, and you can convince enough people to use it and actually give you feedback on sites, and if you got enough users I think there would be other ways of generating revenue (probably selling to Google as someone else suggested would be your best bet, assuming of course they didn't just build it themselves)
[Edit: Google have tried something similar to this before - http://googlesystem.blogspot.com/2008/11/google-searchwiki-launched.html but it seems to have disappeared now so I'm guessing it was an experiment that didn't work]
Another inspiring woman programmer is Niniane formerly from Google and Microsoft.
http://niniane.org/
http://www.ofb.net/~niniane/resume.html
Brief snippets from her resume:
Google:
* Founder, Lively by Google
o Created vision, got project chartered.
o Built and led a team through technical design and implementation.
o Co-inventor on 5 pending patents.
* Tech lead, Gmail Ads
Microsoft:
* Software Design Engineer Lead, Microsoft Flight Simulator
Also featured in Google's recruiting campaign:
http://googlesystem.blogspot.com/2006/05/brilliant-niniane-wang.html
However, she left Google recently after 5 years:
http://niniane.blogspot.com/2009/02/life-updates.html