4 ms·
Ask HN: Is it "dirty" to have an "Import from [competitor]" feature?
Considering a feature in one of our products that would ease migration from a competitor's product. After reading the Loic Le Meur post on here recently, I'm wondering if such a feature is unethical, dirty, low, or un-nice.
Thoughts?
- bdmac97 17y agoUhm... no? Why would it be "dirty" to do that? As long as you have a valid way to access the data you're just doing your customer a favor. I think it's only dirty if you're not upfront with the customer about what you are going to bring in from your competitor and/or what you're going to do with the data.
- chengas123 17y agoNot at all. Especially, if you also offer an export feature. Trapping the user's data in your product is not nice.
- run4yourlives 17y agoMy thought is that it is "dirty" to not allow your customer to easily export their data from your project. If a customer chooses to use a competing product, and you make it hard for them to do so in order to keep them, you've already gone from being a help to being a barrier to your customer. If someone else comes along and removes your artificially erected barrier at their expense, so be it. Perhaps next time, it would pay to work with your customers, and not against them.
- dpcan 17y agoThis is sometimes easier said than done. We have a system that is made up of about 30-40 tables of associated data. The software itself allows many levels of reporting on the data, and we take nightly snapshot backups of the data for restores. So, the customer need not worry about the integrity of their data or getting it back out in a meaningful manner. However, developing a system of export would not only be extremely expensive, but would be done so to allow our customers to leave. We are working on an API that would allow some interaction with the data, and I suppose someone could write a form of export tool from the API if they choose, but I don't think we are going to do this. I can see how important it might be to have export tools for a contact manager, or other small, single-use apps, but it's just not realistic, nor does it make good business sense when you have massive data sets and invest greatly into support and data backups/management.
- run4yourlives 17y agoThe choices you make for you and your app are yours alone, and each must be weighed against your other needs. I didn't mean to imply that exporting your customer's data was an easy or priority job. However, you don't operate your business in a sandbox. We're moving, ever so slowly into a world where ownership of data is becoming a very real concern for many of your would be customers. You will run the risk that either a new customer finds your terms unacceptable, or even worse, that your competitor does this extremely expensive task for you. There are many situations and each deserves it's own investigation. I'm merely stating a design principle that is good to practice.
- tedunangst 17y agohttp://www.joelonsoftware.com/articles/fog0000000052.html http://www.joelonsoftware.com/articles/fog0000000052.html
- mlowe 17y agoWow! Great article! This pretty much sums up why you want to make it convenient for users to export your data.
- Edinburger 17y agoCheck whether you would be violating the Terms of Use of the competitor's product (e.g. by screen-scraping their site). Of course, if you are small you are less likely to be sued so you might want to take the risk.
- jacquesm 17y agoYou know what, if that would be in their 'terms of service' then they can go jump of a cliff. To lock in your users data may be in your terms of service but that does not mean it will stand up in court. Portability is pretty much a given, whether you're the phone company or a web site it should not matter. Any website that wants to play nice opens up their users contents at their request and competes on quality, not lock in to make sure as few users as possible make use of it.
- falien 17y ago"To lock in your users data may be in your terms of service but that does not mean it will stand up in court. Portability is pretty much a given..." It is a given in terms of best practices in various regards, but not in law (at least not in the US or other jurisdictions with similar IP frameworks).
- run4yourlives 17y agoI'd be willing to bet it is, given 10 years or so.
- callmeed 17y agoWell, every one of their customers' sites has an exposed data file. So, I would just be taking their URL and reading the data. Then, I'd just parse it and drop it in to our product (as well as copying images over, but those images belong to the customer).
- aplusbi 17y agoNot at all, as long as you provide an easy and open way to export your data for your users (and potentially your competitors) to use.
- caffeine 17y agoI think you should probably shoot the competitor an e-mail and mention to them that you're doing it (and tell them about your useful export API, and ask if they can reciprocate!)
- Anon84 17y agoAs long as you have a "Export to [competitor]" feature as well I don't see what the problem is.
- MichaelApproved 17y agoI don't even think you need that. Let your competitor break his head writing that code.
- egl 17y agoI second the support for "export from your app". This signals that you're confident that customers will stay with you because they like your product, not because they are locked in. It may not be easy, but it's a way to reduce the risk of entry.
- timcederman 17y agoGmail are a very obvious example of a large-scale product doing this.