Last couple of years or so have been an eye opener for me on how I choose libraries, tools and services for my project. One important lesson was that never choo

Last couple of years or so have been an eye opener for me on how I choose libraries, tools and services for my project. One important lesson was that never choose a service which don't have plug and play open source alternative. Even hyped start ups go out of business and big companies like Facebook and Google shut down services. Third party APIs are a even bigger risk. Facebook and Twitter APIs used to change quite often 2-3 years ago. (Haven't personally worked on this off late though.) APIs and services which seem too cheap are generally the ones which should be avoided. Because it is more likely that the companies running these will not find a sustainable business model. Even Open Source projects get abandoned quite often. Sometimes a team puts together an impressive open source project and then they get acquired by a big company which results in abandonment of the project. I have one client who has his startup riding on Kurento Media Server for WebRTC calls. This product is in development from last one and half years. Now, after Kurento's acquisition by Twilio, Kurento's future is not clear. Also it's not a project which any body can just get into and start developing it further. Thankfully Kurento is not abandoned yet by the development team, but I had read somewhere that they are looking for new maintainers. The lesson learned is only depend on mature open source projects and depend on PaaS services which make those open source projects available as easy to use services. Even if that PaaS service go down, there is a high chance that you will find someone who can deploy and support it for you. However, if you are depending on a third party API or a relatively unknown Open Source Project for critical functionality, treat it as a big risk in your product's future road map and be prepared with a contingency plan. Right now in cloud services there are way too many products which are not easily replaceable. But these are easy to use and sometimes solve really difficult problems. So the temptation to use them is too high. So they still end up in the stack, especially when the clients themselves push for these services to be used.