So what you're attempting to install here is a chrome app[1]. It uses the Chrome Extension/App APIs to create "desktop app" experience. Hangouts as a part of gmail/google+ I believe is supported on Google supported browsers[2].
I love this article. It takes a pro-active, how to proceed attitude at the same time laying out the classic pitfalls that exist. This is the tone I wish to have at all times instead of the cynical one that I undoubtedly adopt.
I think this is a little bit of a trap. Sure the number of people on the service are a feature and almost a meta-feature since it usually enables or multiplies the fun of other features. However the real value is number of active people on the service (which you did write). Those people were enchanted before I, as a new user, showed up. Therefore there is some orthogonal benchmark of quality or delight is required. These features I believe are what make someone get excited and share your app which then makes it amazingly social and draw in "the good people"
I agree with this firmly and have often doubted if it made me a naive "non-marketer". When discussing with marketers I would often point to the idea that our funnel was already resulting in so few long term customers, why would we spend money to pour more people into such a tiny funnel? I think a really good and "enchanting" (to steal from another front-page article) first impression is necessary particularly when demoing to end users due to the large amount of products they're being bombarded with on a daily basis.
So while I agree with your overall stance, I'm worried about the implied advice to wait until your product is good enough. Since the phrase by definition is difficult to assess otherwise everyone would succeed.
I think there are a few key benefits to a centralized manager over the distributed file listener.
1. coordination between services on reconf.
2. Consistent implementation on what constitutes a change through the API on the central server.
By making it API based you can hook into these updates and cause reconfs and coordinated responses (like rolling bounces) through that system as opposed to each system polling the file and hoping that the order comes out in the wash.
You could with enough work make it so that a client was aware of how to handle individual diffs from the file and coordinates through the file but at that point your now distributing common parsing logic across multiple systems (and potentially implementations) rather than a central system which sounds awfully un-DRY.
Internships are paid, I believe that should cover expenses but we can negotiate if you're a fit.
Re-inventing the browser to match how people use the web today. Bringing social interaction and link discovery to the browser itself.
We're looking for interns of all types. C++/Obj-C for native client dev (rooting around in Chromium and building features), JS and HTML for platform application dev, and Java for our back end.
We've had some interns stay with us for the year round, so we can find something that works for you.