NoSQL, Erlang, and Technology's Effect On Economics and Culture
orchestrate.io
orchestrate.io
global labor issues: With high unemployment, and high under-employment, it is said you should feel lucky simply to have a job and to not ask for more.
effect of the two-tier labor market for engineers: I've spoken to many developers who think golden jobs exist all over easily to grab by anyone who will work hard enough. This is not the case at all and the programmers in the companies with slides and free lunches must learn this and unite with the real world or risk finding themselves on the wrong side of labor battle in the future.
creation of a 'reserve army': I think the push for everyone to learn to code shows what the future holds. More and more companies in all fields are having uses for programmers, and the easier it is to replace them with cheaper labor the better for their profits.
anti-labor bias in U.S. culture: More likely the mass of developers are on the "Right" but not because of libertarian ideology but simply being in the United States.
social context of technology use: Simply developing a technology doesn't change the world, but the social battles around it, either directly or indirectly, do.
social progress requires socialism: There is enough food and housing, it simply isn't being properly distributed, and this shows that technology itself can not provide a solution.
The five-year plans were to bring a backward feudal country into the 20th century. That isn't to legitimize the abuses any more than it is legitimize the abuses the US and other countries (slavery and other labor abuses) committed to advance themselves to the level they are at.
The simplest solutions are to redistribute wealth such as through a basic income or a negative income tax. These programs can be viewed as fixing capitalism, and are not necessarily socialist. Unfortunately, most of these redistribution programs will need to be implemented by governments.
As an alternative to governmental redistribution, I have thought about an e-currency with a time based demurrage (https://en.wikipedia.org/wiki/Demurrage_(currency)) fee. The demurrage fees would be paid out equally to all consumers. The demurrage fee plays the same role as a job in the current economy by circulating currency from producers to consumers. Since it is an e-currency, it would be independent of governments. The good news is that if in the future wealth inequality causes economic output to shrink, businesses might be forced to accept these types of currencies in order to grow.
I can understand that when you are pushing for a solution, you make the decision with what's at hand. But this can lock you in to long term decisions, for example people who decided to use Google's app engine. The pricing switcharoo is doubly painful because there is literally no option except rewriting everything!
For this reason, I strongly believe that iaas/paas needs to be fully open source. Don't like your provider? Outgrew a provider? Company perished? Fine, run your own.
We have somehow switched from open source and the freedom that entails, to open API, and a complete lack of freedom.
I am very glad there is a data export tool, I'm sure that will alleviate some people's concern. But the issue is that now someone has a bunch of code written to an API they have no implementation for. That is the nature of the lock in! Vendors discovered in the 90s that open APIs were very amenable to lock in - for example CORBA, SQL and more. It was really hard to port from CORBA implementation to another one, since non-functional requirements dominated at that point, even if at the API/code level it was compatible.
Good luck with your business!
I love the concept, good luck orchestrate
With the definition of “lock-in” that you’re using, it’s very difficult to find any service that doesn’t cause the user to be “locked in”. There is always a cost to migration from one service to another. That cost might be code changes to support a new API or it might be capital expenditures to spin up a cluster of a bunch of different databases to provide the same functionality, or it might be the cost of hiring a specialized team of ops engineers to run said cluster..or all of the above. :)
So, yes, there is a significant tradeoff if you choose to use OiO - you are trading off the cost of building and maintaining a large system of databases for the convenience and speed of development. Even if we open sourced all the code to run the IaaS portion of our system, you’d still have to find the hardware and manpower to run it...and keep it running over the long term. Once you’ve built up your own expertise, you would pay AGAIN if you chose to migrate to something else.
There is no free lunch. Every action entails choice and consequence, but Orchestrate is committed to ensuring data portability and freedom to our users as much as possible, with the hope that they will love it enough to stay and use for a long time to come.