
The start-up code of conduct and ethics - vijaydev
http://www.jacquesmattheij.com/The+start-up+code+of+conduct+and+ethics
======
patio11
No offense, early adopters, but if you desire a SLA like this one from me,
you'd better get moving because only one person will ever get one and my
girlfriend looks like she is the odds-on favorite.

This strikes me as optimizing for the somewhat quirky preference set of a
group of people who do not pay money for software. (People who do pay money
for software have an easy mechanism for determining what they are owed: check
the contract, if it says you're owed it, you're owed it, if not, you're not.)
Their opinion may, possibly, be relevant, but I wouldn't really go out of my
way for it without a darn good reason for why.

There are few startups on HN for whom API stability 18 months from now is a
life-or-death issue for their startup. There are, almost certainly, juicier
fruits which hang lower for your marketing than guaranteeing your API
stability in the event of an acquisition or death of your startup.

If you doubt this, please, post a statement of User Rights or what have you on
your website. Count the clicks to it. People's revealed preference is that
they _do not care_. They might think they care, they might even say they care
("How dare this Mobisocifotogame that I read about on HN close without letting
me download the 5 minutes of attention I put into it in a convenient-to-use
XML file?!"), but _they do not make decisions based on this_. Spend your time
on things that actually influence decisions they make, like e.g. button
colors. Seriously. Tweaking button color on your signup form will, _provably_
, do more for your business than optimizing for the opinions of folks who flit
between new web services like mayflies with less spending power.

~~~
jacquesm
It's voluntary :)

People's revealed preference is that they do not care _until they get bitten_.
And then they care very much.

So we can and should do better than the bare minimum, and better than 'what
users ask for' before they get bitten.

That you do not care is a different story altogether, but consider that if you
align your users' interests with your own that you probably stand a much
better chance of success than if you do not.

Sure, 'greed is good' and all that but in the end, company data being sold in
bankruptcy proceedings is simply bad, companies giving several days warning
before shutting down (<http://news.ycombinator.com/item?id=2770257>) are not
helping anybody (not even themselves), and Yahoo!'s shutting down Geocities
_still_ reverberates around the web (especially the way they went about it,
for a pittance they could have continued to at least store the data).

My inbox fills up daily with people that thought they had an agreement with
one of the largest companies on the web and it turned out they got hurt badly.

Big or small, it does not matter.

We are _all_ operating by the grace of our users and those people that put
their own interests ahead of those of the users are hurting _all_ of us.

Maintaining this sort of integrity is not a cost, it is a long term benefit,
for everyone.

~~~
tptacek
When you use words like "code of conduct" and "this sort of integrity"
assumptively, as you have here, you invite criticism for an idea that would
otherwise be almost so universally accepted as to be anodyne.

On just a second reading, I see the following issues:

* 1.3.2 ("edit" information) will be construed as a mandate that information never be archived (it needs to be "live" to be edited). This is for instance an issue with Twitter, which does not make it easy to find (let alone edit) Tweets from last year.

* 1.6 (least information required) precludes business models that exchange lowered (or no) fees in exchange for user data.

* 2.2.1 puts, in a "startup code of ethics", legal roadblocks to selling companies (do you or I know what is or isn't legally reasonable to promise in something like this? In lots of cases, a lawsuit can easily kill a deal.

* 2.3 puts obligations on a hypothetical third party company to run an extra service

* 2.3.1 requires a _six month_ shutdown notice, by which standard half the companies announced on HN would potentially be required to notify their users at launch.

* 2.3.2 requires, for no apparent reason, startups to open source their software at wind-down --- never mind the fact that most funded startups can't do that, since they _don't own the code_.

* 2.3.4 says, direct quote: "If our shutdown is involuntarily (for instance, because of bankruptcy) the bankruptcy trustee will be bound by these terms"

Actually here I just stopped reading.

If a startup launched with this in their promise to user signups, I'd laud
them. But the person who tries to bind _other_ startups to these ideas under
the aegis of "this is what integrity means" probably deserves some flak.

~~~
jacquesm
Think of it as a starting point, a first rough version of what I think should
be present in a code that binds start-ups to their users to balance the scales
and to make sure that people that run companies realize that they have rights,
but so do their users.

As for 'eating your own dogfood', I fully intend to subscribe all the services
I run to the code of ethics, and I have absolutely no problem with that
limiting my options.

And if your views on integrity do not coincide with mine that's perfectly ok,
but it is really easy to hammer any idea into the ground, let's see your
alternative, something that you think would be an improvement over the status
quo that you would find acceptable.

~~~
mcherm
Jacquesm: Just to illustrate how you have a tendency to Specify unreasonable
upfront restrictions, your own code prohibits you from correcting some of
these errors in your code. Even though this is an 0.1 version, it requires all
future versions to be equally or more restrictive. So you will have to live
with your "first rough version" forever.

That is exactly as stupid as promising to keep the 0.1 version of your api
active forever no matter what even if a serious security vulnerability is
discovered.

~~~
jacquesm
I think that an update of the first rough version before it is adopted for
practical reasons is perfectly ok, but once adopted it should not be possible
to water it down by adopting later versions. That opens the door to adopting a
version without restrictions at all and that would render the whole thing
pointless.

Keeping your API active if there are security vulnerabilities is interpreting
the thing to the letter, the idea is that you will fix the vulnerability and
that you will continue to provide the functionality at the same time. If there
is an unreasonable conflict between the two (and I fail to see how that could
be possible except for very contrived cases) then there probably will be a way
to resolve that conflict to everybody's satisfaction.

I very much like RDL's idea: <http://news.ycombinator.com/item?id=2774133> ,
it solves some of the problems without introducing any new ones.

And it allows for a partial adoption, which is really neat.

~~~
tptacek
When you write things like "bankruptcy trustee will be bound by these terms",
it becomes hard to argue that other people are unfairly interpreting it "to
the letter".

~~~
jacquesm
Still waiting for your alternative.

As for the bankruptcy situation, that's one of those cases where there is
absolutely no loss for the start-up, after all, the people that found the
start-up have nothing to gain once they go bankrupt, but users have everything
to gain because if their data gets sold the buyer will be able to do just
about anything he wants with the data if the conditions have not been created
ahead of time in such a way that they survive the transition.

So, from the point of view of the start-up owner _and_ the users that's a win-
win, it may reduce the value of the assets during a bankruptcy liquidation but
that's an acceptable trade-off in my opinion.

~~~
tptacek
The issue with your bankruptcy clause isn't its reasonableness (although I
personally don't think it's reasonable); the issue is that it's probably not
enforceable. I'm not particularly interested in amateurishly delving into the
nature of executory and non-executory contracts between freemium startups and
their users, but just know that this is not a simple niche in US law.

I'm a very arrogant guy (really), but not so much that I feel like I can come
up with a code of conduct for startups on my own. I've got no alternative to
offer you. I don't think we need one and I'd bet the market is going to agree.

------
rdl
A one-size-fits-all is not going to work, I think.

The correct model is probably something similar to the Creative Commons model
-- create a few bundles of rights, let creators/site operators compose them,
creating a 2x2 matrix of licenses or whatever.

For instance: 1) Ownership of content/derived rights 2) Persistence of terms
through exit (bankruptcy, sale, change of control...) 3) Revocability (can
never, can easily, or can after N day waiting period during which users may
delete all data, or opt in/out of new terms...) 4) Law enforcement: we'll
actively bend over/cooperate like eBay, or we will require warrants and resist
to the extent legally allowed, or technical countermeasures, plus which
jurisdictions (I'm usually fine with USA law, but wouldn't want my content
under e.g. Saudi law) 5) ...

This matters more for power users and API users (developers) than for casual
users, but I agree something like this is necessary.

~~~
jacquesm
That is a very good idea!

------
BrandonMTurner
I am developer at a small start up, in terms of company size at least. There
are only 4 people in the company and I the only full time developer. The CEO
is technical and writes code half of the time himself as well. Though, while
small in size, we have roughly 1.5M uniques per month. Only a small part our
service is read only / consumption based (the forums and other social
networking features). Based on the nature of what our service does we end up
collecting a lot of information on all of our users. Non financial
information, but most of the information we have about users they would never
want other people to know or find out about. Each day the average active user
gives about 10-15 new bits of information (willing-fully, thats why they use
our service, we are not just tracking users to get the information).

That being said, a lot of users when they close their account contact us and
demand us to verify we have deleted all of our their information. We do our
best to anonymize by blanking out their name, location, email address, etc...
in our database. Then we mark the account no longer active.

However, we can never confirm their data is fully gone. We can not
retroactively go back and remove them from our countless number of backups. We
snapshot ever night and keep the backups for differing amount of time. Since
we can never get rid of them via the backups, which basically are just as good
(if stolen, leaked, etc..) as the data in our live database we can never
confirm their data has been deleted.

Would this mean we would be breaking this code of conduct? If so, that would
make this code of conduct way to burdensome for any start up or company to
follow.

(Not to mention other things in there besides the data retention policy that
make this way to much for any start up to promise to follow)

~~~
jacquesm
Backups are hairy, from what I understand the EU directives on user privacy
require that you delete the data from you normal business processes _and_ you
warrant that this data will never again be used actively or passively after
the user requires deletion. The way I deal with this particular requirement on
my site is that if a user requests removal that the deletion request is
archived separately after the deletion. If I should have to roll-back a
database from a back-up then I will run all the deletions against it that were
made since the time that the backup was made.

I'm not 100% sure if that is in compliance with the law but it is a pretty
gray area. As far as I'm concerned I would say that you are doing just fine
and that you operate to the spirit of the document even if you can't guarantee
that in the most extreme cases you'd be following it to the letter.

And that 'spirit' is exactly what this is all about.

------
preinheimer
These sound all nice and friendly, but they're not feasible for me. If you've
paid me, use the service for a time, then ask me to delete all data associated
with your account, I've got nothing to fight a chargeback with.

Shutting down after losing a patent (or other) lawsuit, then open sourcing the
aplicable software seems wrought of peril.

6 months notice is feasible for a paid service, but not so much for a free
one.

~~~
jacquesm
> then ask me to delete all data associated with your account

You may not even have that option:

<http://www.dataprotection.eu/pmwiki/pmwiki.php?n=Main.HU>

As for keeping the history for anti-chargeback purposes, it is my
understanding that you are allowed to keep username and log in data and your
IPSP will have the rest of the information that you'd need to fight a
chargeback.

Also, someone requesting deletion of their data would make it pretty easy to
fight that chargeback because they're providing you with auxiliary proof (the
request itself) that they've been active users of your site.

The patent claim is a good one, I'll have to think about that.

Keeping a free service 'up' without allowing new data to be entered in to the
system post shutdown without support or development costs a very small
fraction of what it would cost to run the service in an active way.

For example, Yahoo! claimed that running Geocities cost them tens of millions
of dollars annually, and yet, somehow I can maintain a large fraction (how
large a fraction we'll never know) of their accounts up and running for
approximately $500 / month.

The problem with giving notice is that many people will never get your notice,
even when given 6 months ahead of time.

Imagine dropbox shutting down their free accounts overnight. It's technically
within their rights. Ditto google docs and a myriad of other services that
people come to rely on.

~~~
preinheimer
> As for keeping the history for anti-chargeback purposes, it is my
> understanding that you are allowed to keep username and log in data and your
> IPSP will have the rest of the information that you'd need to fight a
> chargeback.

If I'm keeping your username, your login and usage history (likely IP address)
to fight the chargeback, I haven't deleted all your data by a long shot.

> Keeping a free service 'up' without allowing new data to be entered in to
> the system post shutdown without support or development costs a very small
> fraction of what it would cost to run the service in an active way.

Keeping anything running has cost, you don't just stand up a machine, step
back, and hope for the best. There's maintenance, patches, IDS work, etc.
Hitting a "read only" flag in your software (presuming it exist) doesn't make
the machine invulnerable.

~~~
jacquesm
> If I'm keeping your username, your login and usage history (likely IP
> address) to fight the chargeback, I haven't deleted all your data by a long
> shot.

I think you are approaching this in too literal a way.

IPSPs typically log IP addresses, usernames link accounts to payments, and are
stored on both sides (with you and with the IPSP) anyway.

But your user uploading pictures, saving content, making spreadsheets and so
on, _that_ user data is the data that is most likely most relevant to the
user.

Their email address is relevant too, if you plan to use it. If you delete
their account but keep a log that the account was deleted at the request of
email address 'x' mailing you from IP address 'y' and that that user had at
the time of deletion logged a grand total of 64 hours on your service over a
period of 90 days then that's just fine as far as I read the law.

Yes, there is a cost to keeping a free service alive post shutdown. And you
probably should factor that cost in to your business plan when you start. And
if maintaining a service in such a way that users can get their data out post
shutdown (and possibly a migratory service or a deal with 'web.archive.org' to
archive the site, which, ironically may be in violation of several countries'
laws) is too expensive then you can wonder if that service is viable to begin
with. Typically those costs are a very small fraction of what it would cost to
run a service in an active mode.

I currently host 3 projects that are officially 'dead', their creators no
longer felt that they were going to spend another dime on them and I feel that
to do right by the users the small amount of money that it takes to 'keep the
lights on' is far outweighed by the benefit to the users.

------
vaksel
it seems pretty restrictive

in the early stage you are required to build extra features....and in the
later stage you are requiring the acquirer to agree to this

~~~
jacquesm
It's actually not that bad.

The first section 1.1 through 1.5 is roughly what the EU law would have you do
anyway, 1.6 is a good way to tell your users that you don't intend to use the
service as a pre-text to harvest more data on them than you need.

The second part has some issues that would come up in an acquisition, but
think about it, if you are placing the wants and needs of an acquirer ahead of
those of your users then you should have never started that company to begin
with, after all, it is more than likely that your users are what gave you the
platform to get the acquirer interested.

A 'pure' team acquisition that kills the product post acquisition is about as
bad as it gets from a user point of view and if you intend to do that then
maybe you should clarify that up-front instead of when it is two minutes to
twelve.

Killing off APIs willy nilly is a very bad nono imo, you basically create an
avalanche of fall-out the consequences of which are probably hard to envision,
especially if your API becomes important enough that people will start to
build commercial services around it.

~~~
synnik
I think you are being unrealistic about acquisition. I hear way too many
discussions on HN about monetizing your products, and people looking for their
big exit/payday. People are not going to give up their exit plan because of an
idealistic "code of ethics" for their users.

~~~
jacquesm
I think we all speak for ourselves here. Maybe it is true that not many
companies would require an acquirer to continue to run the service as it was
at the moment of acquisition (or better!), but I think those that do want to
make such a commitment to their end users should get a leg up.

If someone offered to buy out the sites that I run in order to shut them down
I would refuse.

~~~
rdl
Actually I think it would be cool to ask ~10 big acquirers, both of talent and
of products/tech, to see how they'd feel about deals with these terms.

Google seemed ok with Etherpad running in parallel for a while. The concerns
seem to be: * Acq wants to be able to develop their own products with the
tech, less competition -- shutting off system supports that, but so does
disabling new account creation on it, and making your own product superior.
Some changes seem ok, some seem borderline (flickr -> yahoo login), but just
shutting down a service is different.

* Wanting full resources of the team -- running the old site on autopilot

* If the old service is inherently unsustainable (patent/IP issues, negative marginal income, ...); the former might be a big deal (although YouTube won by having the Google lawhammer on their side), and the latter might not be a big deal if the absolute dollar value involved is low relative to the deal.

Even if a deal ends up being 5% less due to the requirement that the service
stay operating after acq, if it makes user acq easier so you get 2x more users
and thus a 2-10x higher valuation, it's win/win/win/win (acq, founders,
investors, users).

------
phamilton
How many startups actually shut down? When I say shutdown I mean close the
doors, unplug the servers, delete all code and walk away?

If there is any significant codebase, isn't that at least worth something?
Sell it off to the highest bidder?

I think the open source clause under shutdowns is going to be rare.

------
gojomo
This seems like an anti-pivot poison pill.

~~~
jacquesm
I would say the sweet spot for defining your users rights is right after you
gain some major traction and before any kind of exit is even on the horizon.
And definitely before other companies start to rely on you, and/or network
effects have put you in a position where you can afford to screw people over.

Probably it would be a good idea to have your business model figured out as
well.

A side effect of this is that it may force you to think a bit harder over
whether you want to support this creation for an extended period, and that
alone might be enlightening.

So, pivot to your hearts content, but when you feel you have a 'live one'
define your users rights and stick to it.

------
sixtofour
What are some typical contractual agreements for user data of an acquired
startup, between the acquirer and the startup?

------
bauchidgw
anybody remembers the blogger code of ethics? what happened to it? what was
its impact (if any)?

------
4J7z0Fgt63dTZbs
This kills off the root motivation to be Samaritan with power. If everyone can
copy and paste instead of reinventing it, dealing with double binds and trade
offs,they'll grow to put less weight on caring for user interest.

