
NoSQL, Erlang, and Technology's Effect On Economics and Culture  - jenlankford
http://orchestrate.io/blog/2014/03/21/voices-tristan-sloughter-on-erlang-nosql-and-technologys-effect-on-economics-and-culture/
======
jboynyc
Perhaps surprisingly in an interview that's mostly about technical issues,
Tristan Sloughter makes some very smart points about labor:

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._

~~~
mercurial
Interesting interview. However, the notion of a "planned economy", even for a
left-wing person such as yours truly, echoes of dreadful communist five-year
plans. I remember, in Accelerando, the idea of algorithmically assigning
resources, but it sounds very hard to do in practice, even though our current
economic model is both unfair and headed for disaster in the not-so-long term.

~~~
kungfooguru
Our current economic model is also very planned, just not by and for the right
people and reasons.

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.

~~~
mercurial
If you mean that special interests influence government policy, I'll be forced
to agree with you. However, this is widely different from what is commonly
understood as a "planned economy". Nobody sits down and decides of the
economic output necessary.

------
ryanobjc
Great blog article! Good discussion, but there was one element I would like to
see discussed more about these 'store your data as a service' is the hidden
vendor lock-in!

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.

~~~
jenlankford
Hey Ryan, thanks for the comment. So, Orchestrate actually has an on-demand
export tool so there is no lock-in. We backup your data into S3 and send you
all your data in JSON format. We take zero lock-in very seriously :)
[http://orchestrate.io/blog/2014/03/12/new-feature-data-
expor...](http://orchestrate.io/blog/2014/03/12/new-feature-data-export-for-
zero-lock-in/)

~~~
ryanobjc
Thanks for the reply! I feel bad even pointing this stuff out, because I know
that startups have to do what they have to do to make the bread as it were.

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!

~~~
dizzyd-oio
Disclosure - I’m one of the engineering team at OiO. Now, that aside… :)

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.

