Geo-preneur

Advertencia: las opiniones que voy a presentar, son personales, y simplemente representan mis pensamientos desde un punto de vista externo (i.e. todos mis emprendimientos han sido en EEUU) y, tal vez, un poco superficiales, ya que estan basadas en una cantidad limitada de interacciones con emprendedores peruanos.

A pesar de haber usado computadoras antes de que el Internet existiese, este es el primer blog post que voy a escribir en castellano. La razón es que está dirigida principalmente a mis compatriotas peruanos en el área de emprendimiento.

Hace menos de una semana regresé a casa (en San Francisco) de mi lindo Perú, después de haber planeado principalmente una reunión con el equipo de AmigoCloud Perú. Un grupo con gente simplemente brillante del cual estoy totalmente orgulloso.

Durante este viaje, aproveché para reconectarme con amigos que han estado empujando el área de emprendimiento en Perú desde hace muchos años. Entre una y otra conversación, Gonzalo Villarán me convenció en dar una charla en UTEC Ventures (una de las aceleradoras elegidas por el programa Startup Perú del Ministerio de Producción). El tema: ¿Cómo es que se recauda inversión para startups (desde el punto de vista del emprendedor) en Silicon Valley? Este es un proceso que conozco íntimamente después de haber fundado ModeWalk y últimamente AmigoCloud

Este es el link de las diapositivas que presenté

A pedido de otras de las aceleradoras que también participan en Startup Perú, repetí la misma presentación en otros lugares. Después de varias conversaciones con otros emprendedores, llegué a algunas conclusiones acerca del ecosistema de startups en el Perú.

Antes de hablar de los problemas más graves, quiero dejar algunas cosas muy claras.

El Perú tiene mucho talento en el área de tecnología y no tiene nada que envidiarle a universidades extranjeras

Esto es en gran parte a que varias universidades han estado implementando un programa de Computer Science (efectivamente enseñando las mismas clases que son requeridas en universidades como MIT, Stanford, etc.).

Esfuerzos de peruanos como el Dr. Ernesto Cuadros Vargas quien (a mi gran sorpresa) tiene que prácticamente luchar diariamente a través de diferentes medios para justificar un programa de Computer Science real – en vez de una versión que sus detractores llaman “más práctica” ( para un preview de estas discusiones, puedes mirar las conversaciones acerca de este tema en el grupo de la Sociedad Peruana de Computación ).

AmigoCloud tuvo el gran honor de participar en el CLEI 2015; un evento que en mi opinión personal representa las semillas correctas para crecer un ambiente tecnológico de primera en el Perú. Lamentablemente, este evento no recibió la atención adecuada de una prensa que está más obsesionada con investigar si cierta vedette peruana está saliendo con algún futbolista famoso, en lugar de cubrir eventos que van a cambiar profundamente el futuro tecnológico del Perú.

Los emprendedores peruanos tienen el conocimiento y soporte necesario para empezar una startup

Esto lo digo en contraste con una visita que tuve hace muchos años donde di una presentación en Wayra acerca de los conceptos de un Lean Startup.

Este año, cada aceleradora que visité tenía un Business Model Canvas y diagramas de MVPs por todos lados. Era 100% claro que este tema se conoce muy bien. ¡Tal vez hasta debería de pensar en tomar clases acerca de esto en el Perú!

Pero una startup es más que un pitch deck o ganar un concurso de startups.

Creo que para explicar esto mejor, tengo que revisar la oración que escribí hace algunos momentos…

Los emprendedores peruanos tienen el conocimiento y soporte necesario para empezar una startup durante su primera etapa, lamentablemente no existe un ecosistema que soporte las siguientes etapas de vida típicas de una startup

El propósito de un startup es de encontrar un modelo de negocios sostenible y de grande crecimiento. Para eso, se necesitan clientes que paguen las cuentas. Tenemos que pagar a los empleados y tener suficiente dinero sobrante para comprar mesas de ping-pong, ¿no?

Si uno empieza con un modelo de negocios “no-sostenible” (cómo existe al comienzo de una startup por definición), entonces “alguien” tiene que estar pagando las cuentas de alguna manera. Ese “alguien”, es normalmente un inversionista de alto riesgo.

El ecosistema financiero para soportar a una startup durante sus etapas típicas todavía no existe en el Perú

Esto no significa que no exista dinero en el Perú (hay bastante) o que no haya redes de inversionistas ángeles (hay algunas que se están formando).

La realidad es que existe una gran diferencia entre “un inversionista” y “un inversionista de startups”; ni siquiera me quiero meter en explicar las grandes diferencias entre un inversionista ángel y un VC distinciones tan abismales en modalidades de inversión, que es completamente desconocida en el Perú por el 99.99% de startups. Este fué exactamente el tema que toqué en mi presentación en las aceleradoras.

La etapa de crecimiento de una startup (i.e. growth stage) requiere típicamente de inversiones fuertes – todavía en modalidad de alto riesgo.

El efecto más claro de que el acceso a capital de startup no existe se ve en la producción constante de emprendedores que se convierten en professional pitchers: la constante obsesión de participación en concursos de emprendimiento con el propósito de ganar el dinero de la competencia para que la compañía pueda continuar (en vez de concentrarse en crear un modelo de negocios sostenible). ¿Quién puede culpar a los professional pitchers, ¡si esta es la única manera de obtener “inversión” para la siguiente etapa!

El otro problema tiene que ver con el aspecto legal.

Los instrumentos legales (i.e. contratos utilizados en inversiones para startups), así como el sistema tributario en el Perú tiene que ser modificado para incorporar startups

Cuando uno recauda inversión para startups, existen instrumentos legales muy típicos que se utilizan durante este proceso. Gracias a esto, los puntos de discusión durante el negociamiento de la inversión están muy bien definidos, así como la estructura legal de la empresa que se esta formando. Durante cada inversión de alto riesgo, no estamos reinventando estructuras complejas - éstas ya están claramente definidas en su mayoría.

En cuanto a impuestos en EEUU, existen pequeños formularios y elecciones legales especificados por el gobierno que tienen un impacto abismal para el emprendedor durante el crecimiento de la startup.

A pesar de que el gobierno peruano está haciendo buenos esfuerzos para fomentar la creación de startups con el objetivo de crear algo que, de alguna manera, se asemeje a Silicon Valley, existe un elemento fundamental que falta.

Si estudiamos la historia de Silicon Valley, aprenderemos que la creación de este lugar fue en gran parte a causa de la inversión masiva del sector militar

A pesar de que muchos emprendedores conocen la historia de Mark Zuckerberg, Steve Jobs y Bill Gates, es común que se desconozca a Frederick Terman – el Padre de Silicon Valley. Existe mucha literatura acerca de este tema – pero mucho más interesante es que, aparte de la famosa metodología de Customer Development que es tan famosa en todos las aceleradoras en Perú, Steve Blank nos puede enseñar acerca de las historia secreta de Silicon Valley. Este es el único link en este blog post que recomendaría ver:

El cliente #1 de Silicon Valley - directa o indirectamente - siempre ha sido el gobierno de EEUU.

Aparte, si restamos los gastos del aspecto militar, el gobierno estadounidense también consume una cantidad enorme en tecnología (alrededor de $142B USD). Tanto así que, en los últimos dos años, están surgiendo VCs que se especializan sólamente en compañías cuyos clientes son entidades del gobierno.

Lo mejor que puede tener un startup para sobrevivir es ingresos – y si el cliente más grande de Silicon Valley es el gobierno de EEUU, ¿dónde esta el gobierno peruano haciendo algo parecido? (ojo que este no es un problema exclusivo del Perú).

Como peruanos, existen muchas oportunidades que estamos desperdiciando donde podríamos generar una industria nacional de tecnología. Un ejemplo claro lo vemos en la compra de un satélite para Perú que va a ser manufacturado por Francia por S/. 575 millones de soles. En otros países con un proteccionismo económico ligeramente más sensible, se hubiese exigido que un porcentaje (aunque sea pequeño) de la manufacturación de parte del software o hardware se hubiese hecho en el Perú. ¿Qué startups peruanas se hubiesen podido beneficiar de compras a este nivel?

El emprendimiento de por sí es un proceso muy difícil. En mi opinión personal, los problemas descritos hacen el emprendimiento de startups en el Perú super-duper-hiper-recontra más yuca de lo que tiene que ser.

Yesterday one of our developers types 'amazon aws' in their Chrome url which brought this page:

Although the first link says "ad", it looks like the right one, right?

Well clicking on that link brings you to this page:

Look closer at the URL and you'll realize how this is a sneaky way to do phishing. Ugh, I wonder why the ad did not show the full URL in the first place.

I know I have been quiet for sometime. All my energy has been focused on working on the AmigoCloud Mapping Platform. We are finally to the point that we can star Open Sourcing various components and integrating with proprietary systems. If you are curious about what AmigoCloud is, here is a link that explains it https://blog.amigocloud.com/what-is-amigocloud/

Sometimes I just need to visualize a few geometries right at that moment... thus I just need a quick and dirty way to generate a KML/Shapefile/FileGDB/GeoJSON/Whatever with a few geometries. For those instances, I just create a quick CSV with the data I need and a simple GDAL VRT file.

Create a file named test.csv with the contents that you want. In my case, I just want a couple of rows with some arbitrary IDs and a couple of polygons:

id,geo 1,"POLYGON ((-122.3986816406250000 37.7819824218750000, -122.3931884765625000 37.7819824218750000, -122.3931884765625000 37.7874755859375000, -122.3986816406250000 37.7874755859375000, -122.3986816406250000 37.7819824218750000))" 2,"POLYGON ((-122.3876953125000000 37.7819824218750000, -122.3822021484375000 37.7819824218750000, -122.3822021484375000 37.7874755859375000, -122.3876953125000000 37.7874755859375000, -122.3876953125000000 37.7819824218750000))"

Then, create a file named test.vrt and customize it as you see fit:

<OGRVRTDataSource> <OGRVRTLayer name="test"> <SrcDataSource>test.csv</SrcDataSource> <GeometryType>wkbPolygon</GeometryType> <LayerSRS>WGS84</LayerSRS> <Field name="id" src="id" /> <GeometryField encoding="WKT" field="geo" /> </OGRVRTLayer> </OGRVRTDataSource>

In this example, my SRS will be 4326. Now I can generate whatever type of file I want.

Generate a kml:

ogr2ogr -f "KML" mykml.kml test.vrt

Generate an ESRI shapefile:

ogr2ogr -f "ESRI Shapefile" myshapefile.shp test.vrt

Last week's GeoMeetup went well.

This time, our friends at SlidesLive were kind enough to record the three presentations and put them up:

Wolfgang Juchmann (Velodyne LiDAR) brought a LiDAR sensor that displayed realtime point clouds and showed some demos of projects where people were using LiDAR. Just a heads-up: there was a minor conflict between the slide-recorder and the OpenGL software used by the LiDAR sensor, so the realtime nature of the point cloud is not displayed accurately.

Brandon Basso (3DR Robotics) showed how low-cost UAVs/drones are currently being used by farmers to improve crops.

Oliver Guinan (Skybox) talked about possibilities that are enabled when having several low-cost micro-satellites.

And of course, beer.

All these new OGC standards are sadly designed like it is still 1999.

If you don’t like ramblings, then here is the TL;DR for you:

TL;DR OGC Standards should be written for the _future_, not the present nor the past

I have to get something out of my chest. Yes, it is triggered by the current discussions about accepting GeoServices REST API as an OGC standard.

The current focus of the discussion, at the core, is around the issue that the GeoServices REST API is perceived as a set of competing standards (i.e redundant to the WFS/WMS/WCS/etc specs) that don’t have an open (read open source) reference implementation that any organization can refer to when trying to implement the standard.

To me, this discussion is more about politics (which I do agree is a valid topic to discuss) than about the reality of the standards that do come out of the OGC lately.

Reading any of the documents from the OGC make me feel like I am listening to Prince (before!) 1999.

Seriously.

Standards should be written for the future – not the present

I remember several years back when HTML5 was the hot new thing. The standards were being worked on a lot, but most of the browsers did not support any of the features from HTML5. The table at caniuse.com (a place where you could go to see what HTML5 features were implemented by what browsers) were mostly red (i.e. not implemented).

Fast forward four years into the future, most of it is green. That is because those standards became adopted and the functionality that it brought to life makes everyone’s life better.

Designed in the past, adopted in the future. The way it should be.

Contrast this with the current set of standards that we have “up for comment” from the OGC right now…

Before you think that I am against the OGC, let me tell you that you could not be further from the truth. In most presentations that I have given in the last 6 years (at several conferences, some keynotes, and even my own GeoMeetups ) I have always dedicated slides and time to convince/teach people about the OGC and the importance of standards.

Yet, although I have several friends that do work in these standard bodies (I love you guys – you know who you are!), it still feels that there is an unnecessary amount of bureaucracy at the OGC that is truly killing innovation.

OGC is making “standards” that are outdated, unnecessarily overly-complicated, reference implementations that cannot be used as a reference (read below!), and a whole bunch of protocols that resemble what a protocol would have looked like in 1999. They completely ignore what we have learned in the last decade.

Let me give you some real examples.

- WFS, XML Datastores and queries:

XML Datastores were all the academic hype back in the day. Yet they never took off (with reason). The query language used by OGC (which is another OGC standard) assumes the underlying data store is XML. For those of you not familiar with what this actually means, it is more than a representation of something as text. It assumes you have an XML Infoset.

At the core, the OGC spec for Filters is just an attempt to represent SQL as something equivalent to an XPath expression to be used on the web (?!?).

Anybody that has ever tried implementing WFS will understand what this means. Basically, several months of development, to create a parser that grabs an xml document and turns it back into SQL. But to do it correctly, you don’t have to generate one SQL statement, but several ones. Why? Because the query language is so expressive, than in reality you should be able to create expressions that span multiple underlying tables (it assumes it is an XML Datastore after all) which basically makes you just really sad and go home depressed because it is unnecessarily complex.

I have an idea, why, instead of writing a client application that transforms my query into OGC filter speak, goes through a middleware that grabs the OGC filter speak and turns it back into SQL which then goes to my underlying database - instead - do I just not have one method (ExecuteSQL) and be done with it. Use SQL. Let's just not reinvent a SQL. The CartoDB guys seem to have this right in their API . One tiny little api, you pass a string... it does a lot! You know how long it takes to implement something like this? Hours, not months. And you actually have more power than what is expressed by the OGC equivalent. Problem solved.

- XML/GML as a transport mechanism:

This is the mechanism of transport of choice for OGC standards. I have a two year old post about why I think this is far from ideal. Although there are some updates to be made to that answer, at the core, it still remains valid. If somebody tells you that the answer is to ‘gzip’ GML, then, they are wrong (a topic for a future post).

I am still baffled as to why do none of the standards, yet, refer to things like Protobuffers, MessagePack, Thrift, Avro - gosh - anything that we have learned to do better in the past decade!

Switching to any of these, or including them as serialization options would make all the implementations of these standards better/faster.

- “Reference Implementations” that cannot be referenced It is true that a “reference implementation” should be able to be, well, referenced. I cannot currently look at how the GeoServices REST reference implementation (I guess ArcGIS Server) is implemented internally, thus, the specification fails at having a valid reference implementation.

Does that mean that for a reference implementation to be useful it needs to be Open Source?

Maybe that is not enough.

Some people would argue that the reference implementations for the OGC GeoPackage spec, Spatialite, is arguably also not a good choice.

Why?

Because you cannot copy/paste or even create “derivative work" from it without also having to GPL/LGPL your work. Is looking at a reference implementation, seeing the internals, and copying how it works considered derivative work? Those are the type of questions that no developer wants to deal with, so IMHO, the OGC has the responsibility to pick reference implementation that in unencumbered by these issues. By picking Spatialite and a proprietary server (ArcGIS Server) as reference implementations to their respective specs, the OGC is showing that they are either 1) really clueless about these type of issues, or 2) don't care. Either way, this is horrible.

- Websockets?

I wish! Where are the implementations that take advantage of full duplex communications? Server side push? Seriously, are we still assuming users are going to poll all the time and transfer state in every request? This is exactly why most real-time tracking implementations are done incorrectly. Why are we still stuck in a stateless architecture design? We can do server push now without Flash or Java (or Silverlight yikes!). Websockets exist. USE THEM.

I touched superficially around this topic in the last PyCon. The video is up if you are interested.

- Https, Authentication/authorization, security

I don’t even want to touch on authentication/authorization around all the OGC specs. OAuthv2, or even the first version of that are far better than what is expected of the current implementations of security. Most people rely on passing USERNAME/PASSWORD in the request. This is horrible.

But wait, I guess if I use https that means I am secure right? Hell no!

Look at this video from last year’s Blackhat (quite awesome actually) and then come back with a straight face and tell me this is fine.

** - SPDY** If you do not what SPDY is, then, you will definitely be surprised to tell you that all your https traffic to Google , Facebook and Twitter is not going over “traditional” SSL.

Yes, they use a special protocol called SPDY.

It is faster than traditional http (even though it is going over an encrypted channel!). Think about this for a sec.

Does the OGC use SPDY? Of course not. Does it make a difference? Check out this video of last year’s Google I/O about SPDY and you be the judge.

- Non-blocking servers.

The Mapbox guys get it. They use node.js for serving their tiles. Do you want to understand why this is a good thing? Check out this presentation by Ryan Dahl 3 years ago which gives an overview of why this is the case.

Anyway.

I can go on and ramble forever, but I want this to be more constructive.

**The discussion around OGC specs should be about what GIS is going to be like in 5 years in the future. **

Why did the OGC not work with the W3C to push WebSQL through (now stalled)? Imagine spatial extensions in every browser on the client side?

Why don’t we have a good spec about spatial replication, spatial changetsets, optimistic/pessimistic/long-transaction versioning, etc?

Why don’t we have specs that take advantage of web stateful connections?

Why don’t we have a spec for highly compressed geometries?

Why don’t we have a spec that defines better editing capabilities? (hint: WFS-T is not enough for several editing workflows)

Why don’t we have a spec that defines how to truly take advantage time-based datasets?

The list goes on.

Instead, the community as a whole is having long discussions analogous to the one about whether 3857, 3785 or 900913 was a better number for the Web Mercator definition.

Listen OGC, want to see a good standard definition? Check out MBTiles. Easy to implement, and to the point.

I sometimes get surprised to find out that some people don't know how easy is to get GIS packages on Ubuntu. UbuntuGIS is really one of the easiest ways to get up and running. You will notice that there are two repos.

UbuntuGIS "Stable" which has really old packages. You most likely don't want that.

UbuntuGIS "Unstable" which is really not unstable at all. It just has newer packages. You do want that!

To get it working in your Ubuntu system add the ubuntugis-unstable repo:

sudo add-apt-repository ppa:ubuntugis/ubuntugis-unstable -y sudo apt-get update sudo apt-get upgrade

Now you can install all kinds of cool packages.

sudo apt-get install postgis gdal qgis

Is an example of how to get gdal, postgis and qgis ready to go.

I took these a couple of months ago. Man, I miss Perú. The 360 views came out a lot nicer than what I expected

My PyCon talk video is up in the PyCon video site.