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.
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.
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.
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.
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.
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.
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".
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.
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.
I think you have mis-assessed: it's not the "early adopters" who want this, it's the mainstream.
I believe that if you achieve mainstream success with an important service--and appointment reminders are a lot more mission critical and time sensitive to small businesses than bingo cards to primary school teachers, so it may happen to you perhaps sooner than you realize--then you will have to adopt something like this.
If you leave your clothes at a dry cleaners or your car at an airport parking garage you expect to get them back. There are a number of well worked out rights and penalties to make sure that the business doesn't shut down on a few days notice and trash your property. Your customers' appointment reminder data has a non-trivial amount of value to their business. Finding ways to regularly export it or otherwise protect your customers from your failure is in your future if you are successful. Your contract does not do that currently but it will if you are successful.
Codes of Ethics are usually written to suit ideals, and not pragmatism. It's not expected that everyone will actually adhere to everything in a code of ethics---only that they would appreciate that these are "good things" in general, and try to implement them if they are practical.
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.
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)
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.
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.
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.
> 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.
> 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.
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.
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.
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.
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).
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.
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.
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.