Awww.. you mad... I'm so sick of hearing about all these "new" technologies that are so revolutionary, but can't hold a candle to postgres and memcache.
Despite what the brochures tell you, a "degree" from DeVry and 3 hours in a Ruby book doesn't make an architect, and this is one of several "revolutionary technologies", like Ruby, that won't scale and will wither and die.
This is a terrible hit to the team. I lost one of my co-founders at a very young age.. Brandt Cannici was his name, and we really never recovered from the loss. My condolences and best wishes to his family, friends, and the Diaspora team.
I assume you are afraid of reprisal from Google by not mentioning which application(s) they allegedly removed. When trying to rally support, more evidence is better than less, more detail better than none.
first.. identify their role, and yours. Be clear about it. It's the first thing they'll ask you after you tell them what the company will be doing. The lines need to be very well defined, especially if you don't know this person, so that the roles don't conflict.
Before you "find" one, do the above. Then repost :)
| And just because they're operating at a different scale as you doesn't change the fundamentals.
What? Which fundamentals?
Google licensing the data from the provider doesn't make it less expensive for anyone else, it makes it more expensive. They get exclusive licenses that allow them to resell access, thus removing a potential vendor from the pool of possible vendors, and making Google ultimately the only vendor available as they tie up the access points.
I suppose as long as you're okay with Google controlling your access to the information you require, full steam ahead.
That still doesn't change the fact that you no longer control the future of your business. If that's the path you choose, Google owns your business. If they decide to deprecate the very data your business depends on, you're done.
It's about risk mitigation as it pertains to the use of third party APIs. I believe there are too many startups basing their businesses on the APIs of others.
Had I simply written about risk mitigation, it would have been up to the reader to apply it to the use of API's, which clearly startups are not doing.
With respect to the use of those APIs as a core business function, the viability of their continued use is only as secure as the CEO of the company that offers them is honest.
If history is any measure, that's not very secure.
Google licenses the data, but has the resources to acquire the data, and the company that owns it. If you go to the vendor and try to license the data, the cost is now so high that a startup without funding will be unlikely to afford it.
With the exception of "employees", you are correct.
Each is a single point of failure that should be considered, each with its own set of criteria. If there is a sufficient supply of vendors, then the single point of failure (or sourcing in this case) does not pose a threat to your "business".
In the event where the payment processor keeps your customers credit card information, for example, you risk losing your customers when you have to go back to your customers to re-acquire the data should the provider cease to exist, or their policies prevent them from being used. This can be mitigated by using gateways that don't hold the data (like PayPal) as an exclusive processor, and managing that data yourself.
Risk mitigation should be applied to every aspect of your business that has a reasonable risk of becoming a choke point for operations.
Except that throughout the years, the manufacture of cars has become commoditized, and there are many more engine manufacturers than there were, so it's virtually impossible for a single manufacturer to corner the market on engines. Additionally, since the parts can all be fabricated by a multitude of vendors, there's no risk to the car company of a single point of failure.
Sure. I've programmed PHP for the last 8 years, and C/C++ for 18 years before that. A few months back I picked up Python in about 5 days, dabbling part time. Django on top of Python took another day or two.
I now consider myself an advanced Python developer. It's actually much easier than PHP, but the lack of curly braces, and strict adherence to MVC were my initial hurdles.
I can't imagine going back to PHP at this point, even though everything I did in PHP was highly object oriented.
Despite what the brochures tell you, a "degree" from DeVry and 3 hours in a Ruby book doesn't make an architect, and this is one of several "revolutionary technologies", like Ruby, that won't scale and will wither and die.