Mandate

[Aral Balkan]

To create a basic list of rights (e.g., Developer's Bill of Rights)
and possibly a logo certification program that API providers can sign
up to show that they are Developer Friendly.

Thoughts?

[Pelle Wessman]

Also maintain a list of API providers and how they comply with the
defined rights.

Perhaps split the list of rights into a couple of different sections
like Terms of Service, data ownership and open standards compliance
and grade providers in each category.

If an initiative like this gains traction then providers complying
with basic developer rights will promote that - I think no sign up
process is required - this can be completely community driven.

/ Pelle

[mudegwah]

I think if some 'big hitter' API types can be brought on board, and we
make enough noises at all the conferences, then it may take off.
Guarantees of backwards compatibility and notice of changes would
probably be a good cornerstone. Then an API is awarded a "Dev Rights
Interface" mark that is a linked from the site Aral registered. Allow
you to cut people off who break the rules, or worse start serving a
Fail mark...

What you really need, along with some good grass roots support, are
API providers that carry serious weight. Ideally, people who already
behave in this way, so it's no problem for them to adopt. Off the top
of my head I'm thinking PayPal? Their versioned approach is quite
cool. Get them in, and then push for those that don't to 'join the
club'.

[Aral Balkan]

Good idea, we could have a rating system, similar to how businesses
are rated based on their ethics.

I think that's entirely compatible with a logo/image/quality
certification scheme of some sort + a list of basic rights.

Aral

[Stuart Herbert]

Mmm ... if you could get a site like ProgrammableWeb to recognise the #devrights charter, and include that in their list of data about APIs, I think that would be a great way to help spread the word.

Best regards,

Stu

--

--
--
Stuart Herbert

e: stu...@stuartherbert.com
t: +44 7966 284577
w: http://www.stuartherbert.com/
b: http://blog.stuartherbert.com/

[mudegwah]

Maybe we need some sort of plan...? I think the basic idea of what's
needed is fairly clear, everyone seems to be on the same page.

[@ikbenmartijn]

Rating system is a very good idea, but we need to make sure that the
criteria remain transparant to all parties involved and are objective.

[Pelle Wessman]

I think that's to get a bit ahead of ourselves. There needs to be a
list of rights before any promotion is needed. Lets focus on that and
see if any promotion is needed when it's done.

/ Pelle

[Neil]

I think we need to be careful not to discriminate against independent
developers who create APIs.

Settings things such as a guaranteed human presence or an SLA that
would require a huge hosting budget I think would be unfair.

Rather I think we should stick to more human controllable issues such
as what will result in us getting block. What sort of noticed we'd be
given. How are disputed handled.

Neil


On May 13, 2:54 pm, Fending <brianfend...@gmail.com> wrote:
> A cert process should be a sort of service level agreement (SLA) for
> Developer Care -- minimally,
>
>   1. a commitment to having somebody in a chair from X->Y GMT taking
> care of emergent issues,
>   2. a documented dispute resolution process, and
>   3. a commitment to TALK BEFORE YOU BLOCK.
>
> Too unlikely to get past the lawyers who wrote the TOU/TOS to begin
> with?
>
> Aside: Under such a model, beyond the provider "looking bad because
> they broke a promise" in the event of breach or change of wind
> direction, what can our considerable numbers do en mass to exact a
> favourable result?

[Aral Balkan]

I agree that the list of rights should be kept as simple as possible.
I don't think this is about SLAs (correct me if you think it should
be) but rather basic rights (like not getting your app randomly
disabled without notice; not breaking backwards compatibility without
first informing developers, etc.)

Aral

[Martin Pilkington]

One thing that should be an absolute requirement of any 'certification': good, comprehensive API documentation. One thing I have found is that you rarely find both but often find neither. It's hard to be developer friendly if developers can't easily work out your API.

Thanks

Martin

[Fending]

@Neil - Perhaps I stated that a bit strongly... No, definitely stated
that too strongly - thanks for calling it out.

As an small shop (not far off from an indi developer), I cannot fathom
putting something out there without a plan to support it. [Even if the
plan is, "This is not supported."] That said, you're right - perhaps
this doesn't need to be a "body in a chair" SLA after all. When you
think about it, we all want people and companies to live up to our
expectations. Sometimes, people expect too much of small firms and
indi developers even on contract development engagements, so we have
to reset those expectations. Then we more forward in setting those
expectations more clearly in the future.

In the case of even very large firms like Facebook, I think it's
reasonable to expect that they set expectations and then make every
effort to meet them. These expectations should be reasonable ones,
like my #'s 2&3:

2. a documented dispute resolution process, and
3. a commitment to TALK BEFORE YOU BLOCK.

Restated,

A. a documented dispute resolution process,
B. a commitment to engage developers before blocking their app in
part or whole, and
C. a heads-up on changes.

I really do think those parts in some form should stand.

Thanks again/@fending

[Neil Ellis]

I think you captured the core principles:

A) I think people can easily knock up some bureaucratic mumbo jumbo to sound like they will deal fairly with other people in my experience. A simple agreement to arbitration through a recognised (by this org.) independent 3rd party would make sense to me.
B) Illustrated by @Aral today! Top priority for everyone I'm sure - an agreement to engage is essential - otherwise we have the rights of sweatshop workers (but thankfully not the lifestyle).
C) Well I think we can mention Apple here :-) It is essential that people don't work for 6 months on an app to only find they can't actually use it due to a T&C change!!

Neil

[Neil Ellis]

Sorry I realised that this will get confusing if I sign off with just Neil ;-)

regards

Neil Ellis

[Scott Wilcox]

Hi folks,

I think the most important thing that we need to look at as a collective, is the communications process between API providers and developers. Requiring *any* form of SLA will get you immediately ignored in my opinion. A lot of providers just don't have the time, will or need to invest in such a flimsy request. The biggest complaints among developers that you will see are for app's being terminated/rejected, broken compatibility without notice and no formal dispute mechanism.

Scott

Scott Wilcox

t: +44 (0) 7538 842418 

+1 (646) 257 0580

e: sc...@dor.ky

w: http://dor.ky

http://synfinaty.com

[Nick Martin]

+1

Ah was just writing the same kind of thoughts down and Scott hits the nail on the head :)

[Aral Balkan]

I agree, this should be about _basic_ rights, not an SLA.

If you make it too onerous, no one will engage with it. We need to
make it so basic that they can't ignore it.

Aral