The acquire-hire-kill cycle for startups that target developers has become really frustrating. I'd love to try a lot of these new products, but it's hard to know if it's worth my time.
Like, don't build on top of freaking closed source platforms and after 17 years of OSI, 24 years of GPLv2 and myriads of open-source alternatives available, you'd think people would learn.
Of course. Because Gimp does all the thing Photoshop does
Blender does all that Maya does I'm sure as well.
SCADA systems for industrial control? Just download the first one that shows up on Google.
EDA systems? Sure, there's a GPL alternative. People use Mentor (as an example) because they don't know better.
It actually does, for the majority of the population. Which doesn't matter. Any Photoshop alternative must be a clone of Photoshop.
For most people, yes. Unfortunately Photoshop is pirated, so it isn't being used at face value.
> Blender does all that Maya does I'm sure as well
If you want to build your own stuff, which isn't uncommon at all and if you have a movie budget of 100 million dollars, you might be better off forking Blender. Also, Autodesk's Maya is not a startup and it isn't being used necessarily as a platform, so that's building a straw-man on your part ;-)
> SCADA systems for industrial control?
You mean Eclipse SCADA?
Funny thing is that I'm working on a software system using it right now. My mission is to steer and monitor power plants and nothing on the market was suitable for my needs. Building on top of an open source stack helped tremendously.
But yeah - Pretty much agree. The fact that most oss products are best-of-class makes the choice even easier.
a) look at building your own. What's inconceivable to one person may not be to another.
b) Build support for at least two closed-source alternatives, and make sure you always have at least two current alternatives.
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.
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.
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).
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 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.)
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.
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.
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.
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.
Is it simply a case of the acquirer wanting the technology and maybe the personnel while the acquired company is losing money hand over fist so they just shut the company down?
The acquirer may love the technology and use it internally, but it's expensive to keep it in a public marketplace. It requires support staff, marketing, sales, etc.
There are also acquisitions that are purely about customers, so the startup's product is shut down or rolled into the acquirer's existing products.
So there are a lot of good reasons you'd want to company other than its product, but we can't always tell which reason it is right away.
"Technology" is rarely re-used per se.
I wonder how often this actually works. In most cases where I've seen this (or heard of it happening first hand from people I know) the vast majority of the people you'd want to keep were out the door of the new place pretty close to as soon as possible (meaning, as soon as the contracts allow, or the golden handcuffs are mostly off, or whatever is relevant to the specific situation).
On the inside there tends to be a pretty predictable path: New management tells everyone nothing will change materially, everything inevitably changes very quickly, people get disgruntled and take off for other opportunities (at a quickly accelerating pace as the old guard sees all their former colleagues from the old place leaving the new).