|
|
|
|
|
|
by _delirium
5547 days ago
|
|
|
I like Yosef K's six criteria for deciding whether to adopt an external dependency: http://www.yosefk.com/blog/redundancy-vs-dependencies-which-... It's not only that developers are always confident they can do things themselves (though that's common), but that me using your thing actively introduces a dependency for me. If that saves me a huge amount of work and your dependency doesn't seem too scary, that's still a win. But dependencies have a whole host of issues of their own: is this thing unwieldy, do I actually understand what it does, is it well documented, is it going to be around and maintained, if it's for-pay is that pricing going to stay stable, is the API going to be stable? Etc. |
|
|
1. Stability and security will be maintained by a gradual roll-out and a user-driven testing phase. We're still working out the details on this.
2. A standard documentation format is a key requirement for each documented API call; no call will be released for general usage until it has all included information (parameters, possible success and error results, example response).
3. Pricing / service contracts. We are looking at providing guarantees on pricing stability and uptime, and we're thinking of not charging in advance, but after service has been rendered.
4. Source release pledge. It's too early to know how to proceed with open sourcing, but we do expect that at a minimum our client libraries will be open source. And we will pledge to release all code if there were to be an impending service shutdown, with three months minimum for transition.
I think that's all we can do when starting out to show that we aim to be a reliable component. The real evidence probably can't come until we earn a reputation over the coming months.