Hacker News Reader

Comment by smt88 | Hacker News Reader

This doesn't have to be the case.

What if startups with high switching costs (DBMS, OS, pretty much anything else infrastructural) added a guarantee to their sales contracts?

For example, it could be that, if they get acquired, they'll open-source the technology, sell it to another for-profit entity that will maintain it, or provide a migration tool.

Even for something like FoundationDB, it'd hardly be any skin off Apple's back to have a few employees spend a few months ensuring that previous customers have some sort of support.

View on HN

>What if startups with high switching costs (DBMS, OS, pretty much anything else infrastructural) added a guarantee to their sales contracts? For example, it could be that, if they get acquired, they'll open-source the technology, sell it to another for-profit entity that will maintain it, or provide a migration tool.

That would be like them putting a huge paper hat on their head, saying "I'm not a good target for acquisition".

Companies buy them so they (also) get their product/IP etc. If those startups have promised to give it away in such a case, then they are not that good of a buy.

Those are just contingencies if the acquirer doesn't want to sell the product anymore. Basically it's a guarantee that, even if they get acquired, their customers won't be punished.

That scenario won't hurt companies that are being acquired with the intent of keeping the product running, for obvious reasons. It also shouldn't hurt acqui-hire scenarios.

The only time it might hurt is when the acquirer wants to use the technology internally, but not offer it to anyone else. That's fairly rare, and the downside (potentially scaring away that tiny fraction of acquirers) is much smaller than the upside (making potential customers feel safe).

It's hard to really guarantee effectively without putting up serious money.

The typical large closed-source codebase is full of undocumented things and hidden dependencies on random chunks of proprietary environment. Making it usable as open source is a ton of work.

And you can't guarantee that work will happen without putting up some kind of bond or buying insurance, given that the vendor could simply go bankrupt and not honor the contract.

This is simply the risk you take being an early adopter. If you are uncomfortable with the risk then choose something from IBM/oracle/et al.

I do choose established providers. The problem is for the community as a whole -- each company that this happens to is another hit to the credibility of early startups.

Or choose free software. If it's free software, even if the original developer goes away, you can hire someone to keep working on it, or someone else can decide to make a business supporting it, or the like.

Or you just get left with a broken OSS project whose contributors moved on to shinier things, and nobody really much cares about continuing it, and you don't have the knowledge/time/resources to hire someone to do it.

But if the product is already working, chances are that you get away long enough (to do a graceful migration) by just doing small bug fixes, changes to support OS updates, etc.

This is what we are now doing for a project with Berkeley DB XML, which hadn't seen updates for five years. When there finally was an update, it was buggy and moved to the Affero GPL 3, which conflicts with other open source licenses used in the project. So, we continue to use the five year old iteration with a small set of patches.

(Lesson learned: once a product is owned by Oracle, prepare your evacuation plans.)

I was agreeing with the previous posters until I realized this has kind of happened to me. Tastypie was the go-to REST package for Django 3 years ago. Now it has kind of been abandoned and everyone is ranting about Django-REST-Framework.

Fortunately it is stable (for my use cases), and it doesn't actually seem ton be that big a deal that it isn't being worked on. Django_REST_framework is a lot nicer though.

One of the problems you get is that once something is stable, the maintainers generally don't have a huge incentive to dedicate already-over-committed time to work on features they don't personally need. Just triaging tickets on a popular project can be a major time commitment, particularly since a fair percentage of them will be helping people understand the API or trouble-shoot something in their project which is causing failures in your code.

In the case of tastypie, I think all of the maintainers have switched jobs at least once in the last few years and at the same time the general Django community has been moving in the direction of simplicity rather than complex generic frameworks. Daniel's list of things he's not interested in implementing in restless is a good list of things which have been painful in tastypie: https://github.com/toastdriven/restless#anti-features

I've only been a minor contributor but I've increasingly found myself favoring really simple views – roughly https://docs.djangoproject.com/en/1.7/topics/class-based-vie... – since I work almost entirely on read-only public data.

If you or someone you know would like to work on tastypie, we're looking for new maintainers:

http://toastdriven.com/blog/2014/may/23/state-tastypie/

If you have an urgent patch, let me know & I'll see about merging it.

Like I say, it is stable for what I am using it for just now.

I have started using REST framework for other parts of the project, and it seems a lot more consistent with Django's other components (serializers are similar to forms, APIViews are similar to the generic views). In the end that just makes things easier. Its less context switching essentially, which is really useful when I don't touch that part of the project for a few months, then need to update something.

Thanks for the offer though (and thanks for the framework, it has been useful). And unfortunately I don't have the time to help with maintenance.

Even if you get a few months of reliable support, you still have to switch which will cost you dearly.

Often what is done is source escrow. The source is given to a third party, and if anything goes wrong the third party releases the source to the one who purchased the product.

Even this sounds like a bad outcome for users of the tool. One minute you're building a product, the next you're stuck maintaining a closed source database.

Reply on news.ycombinator.com