Skip to content

Instantly share code, notes, and snippets.

@colltoaction
Created April 26, 2017 21:26
Show Gist options
  • Save colltoaction/514de738f839ec3ffff235aea5969de4 to your computer and use it in GitHub Desktop.
Save colltoaction/514de738f839ec3ffff235aea5969de4 to your computer and use it in GitHub Desktop.
Presentación para el Meetup NetBaires del 26/04/2017
<!DOCTYPE html>
<html>
<head>
<title>Open Source en Microsoft</title>
<meta charset="utf-8">
<style>
@import url(https://fonts.googleapis.com/css?family=Yanone+Kaffeesatz);
@import url(https://fonts.googleapis.com/css?family=Droid+Serif:400,700,400italic);
@import url(https://fonts.googleapis.com/css?family=Ubuntu+Mono:400,700,400italic);
body { font-family: 'Droid Serif'; }
h1, h2, h3 {
font-family: 'Yanone Kaffeesatz';
font-weight: normal;
}
table, th, td {
border-collapse: collapse;
border: 1px solid black;
padding: 4px;
}
.remark-code, .remark-inline-code { font-family: 'Ubuntu Mono'; }
</style>
</head>
<body>
<textarea id="source">
class: center, middle
# Open Source en Microsoft
## Mi experiencia trabajando en EF
---
# El equipo
* EF6 + EF Core
* 100% open source
* Pocas personas
* Estructura plana (vs devs, soporte, testing, PMs)
* https://romiller.com/2017/03/06/im-leaving-the-ef-team/
???
Lo primero que noté fue que es un equipo chico, y que todos son desarrolladores.
En Microsoft suele haber divisiones en soporte, testing, project managers,
y muchos otros. Es incluso más llamativo que en este equipo el desarrollador
esté en contacto directo con los clientes.
Fui intern en otro equipo antes de EF y puedo dar fe de esto.
Siendo EF una parte bastante importante de muchos proyectos,
y habiéndolo usado en mi laburo antes de entrar al equipo,
inmediatamente empecé a matchear caras con nombres o con alias de GH.
Me puse a buscar, y encontré issues de hace un par de años en los que tuve
charlas súper interesantes con los mismos devs con los que había entrado a trabajar.
Si les interesa un poco el chusmerío, Rowan Miller se fue del equipo durante mi estadía
y escribió un blog post súper interesante y con muchos detalles de su historia de casi 10 años en este equipo.
---
# Open Source? Microsoft??
### Mi respuesta (no oficial `;)`)
Razones principales
* Microsoft perdía mercado
* El nuevo modelo de negocio enfoca en Azure... no en Windows
Otras razones
* Open Source + soporte de Microsoft = empresas contentas
* C# siempre fue un gran lenguaje, buen diferencial
* Cross-platform y OSS van de la mano
* Windows genera rechazo
* Desarrolladores más contentos
* Fomenta esfuerzos de desarrollo libre comunitarios
???
No tengo respuesta oficial de por qué Microsoft empezó a hacer OSS.
Personalmente, me parece que se dieron cuenta de que estaban perdiendo mucho terreno
frente a otros ecosistemas más abiertos y muy participativos como el de Node.
Node empezó a sacarle terreno a otros lenguajes mucho más establecidos.
Si bien C# siempre fue considerado un muy buen lenguaje
(en general, avanzando más rápido que Java, su competidor directo),
Microsoft lo tenía atado a Windows y generaba rechazo y excluía posibles usuarios.
Microsoft hizo un giro a un modelo menos enfocado en vender licencias de Windows y más enfocado en Azure,
y llevó de la mano un cambio de estrategia de negocio en .NET.
El objetivo de .NET sigue siendo dar al desarrollador un ecosistema muy sencillo
para desarrollar aplicaciones empresariales, pero además con Azure como la plataforma con mejor integración,
sea eligiendo Windows o Linux.
---
# Ventajas para el desarrollador
Acceso al código de las herramientas nos da:
* Más facilidad para explicar errores
* Flexibilidad a la hora de buscar workarounds
* Capacidad para resolver ciertos problemas por nosotros mismos
Cross-platform nos da:
* Libertad de elegir nuestro sistema operativo
* Más herramientas (alguien usaba la terminal con .NET?)
Alternativas + competencia = todos más contentos
???
Espero que no haya resultado muy aburrida esta historia sobre el modelo de negocio de Microsoft,
pero me parece importante para entender cómo llegamos a donde estamos hoy.
Como desarrolladores, muchos empezamos a ver las ventajas de tener acceso al código de nuestras herramientas,
y en lugar de necesitar comprar soporte corporativo y esperar días o semanas hasta que se resuelva un ticket,
poder lidiar directamente con los problemas.`
Hay mucho valor en poder descubrir por uno mismo por qué se levanta una excepción
o las cosas no andan como uno esperaría cuando usa una herramienta externa.
Microsoft tuvo el monopolio durante muchos años, pero cuando muchos estábamos
cada vez más entusiasmados con cambiarnos a Linux o Mac y algún lenguaje más abierto,
las cosas empezaron a cambiar para mejor para los developers.
---
# Todos contentos?
### Cambio de cultura
* Curva de aprendizaje
* Nuevas herramientas
* Frustración
* Menos bibliotecas que el Full Framework
* Qué me importa Ubuntu y Docker y todo eso?
* Soporte pago != soporte Open Source
### Cambios internos
* Equipos más reducidos
* Mayor responsabilidad
* Hay que lidiar con personas (puaj)
* Hay que dar soporte a plataformas en las que no se tiene experiencia
* Hay que poder mantener la cordura y lidiar con trolls
* OSS no es trabajar a puertas cerradas y tirar código en GitHub
???
No todos están tan contentos. Una de las dificultades de trabajar en OSS es lidiar con la gente.
Hay personas muy duras, que no cuidan las palabras, y que escudándose detrás de un teclado
atacan el trabajo que uno hace realmente con mucho esfuerzo.
Cuando quise dar esta charla y hablar de Open Source “en Microsoft”, y no de OSS en general,
una de las cuestiones que daban vuelta en mi cabeza es la creencia de la gente de estar hablando con “Don Microsoft”,
y no con un simple dev. Sienten que tienen derecho a exigir soporte, cambios, tratamiento especial,
solo por el hecho de que Microsoft está detrás del proyecto.
Pero la verdad es que nos manejamos muy independientemente. Que es increíble el trabajo de este equipo
que llegó a tener alrededor de 60 personas y ahora se mantiene y sigue siendo súper productivo
incluso siendo casi un octavo de la gente.
Desde que se lanzaron los frameworks Core, como .NET Core, ASP.NET Core y EF Core, la gente está puteando bastante.
Lo primero que va a descubrir un desarrollador .NET de toda la vida es que tienen menos features que los anteriores!
Y hay mucha gente que no entiende la ganancia a largo plazo que tuvo esta decisión,
más allá de que en el corto plazo haya que acostumbrarse a un nuevo framework.
Y peor aún, los que saltan a la pileta de .NET Core sin estar dispuestos a adaptarse,
y sin entender que .NET Full Framework sigue siendo una opción más que viable!
Algunas de estas personas son las que deciden escribir atacando tu trabajo.
Uno tiene que recordarse muy a menudo que en GitHub, así como en cualquier comunidad de internet,
hay trolls, porque si no corre el riesgo de caer en la creencia de que está haciendo mal su trabajo
y todo el mundo odia tu proyecto. Son muchos los comentarios hirientes
y que no buscan generar una discusión constructiva, pero hay que recordar que por cada uno de esos
hay muchísimas personas usando tu producto sin problemas. En especial uno con tanta visibilidad!
---
# Una comunidad activa
* Discusiones interesantes y positivas
* Contribuciones y proyectos 100% de la comunidad como Postgres
* Providers externos -> producto base más robusto y extensible
* Ahorro en horas de desarrollo y testing
### Integración con la comunidad
* Triage varias veces por semana
* Reuniones de diseño
* Tiempo dedicado a evaluar PRs
* Propuestas de diseño públicas
???
Cuando tuve que diseñar una nueva feature, me apoyé mucho en la comunidad además de mi equipo,
y presenté una propuesta que tuvo feedback y validación por parte de quienes estaban suscriptos
a las notificaciones del issue en GitHub.
---
# Cómo arrancar en OSS?
### Barreras principales
* Encontrar algo para hacer
* Procesos complicados o flaky de compilación y testing
En este punto, es fácil hacer algún fix o cambio chico. Mandá un PR!
### El proceso de code review es tedioso
* Aprobación del diseño -> no todo se toma
* Cambios grandes -> separar en múltiples PRs
* Tiempo de respuesta lento
* Estilo y formato
* Cambios en la API pública
* Bugs
* Tests
???
Los proyectos grandes suelen tener procesos algo complicados o no-estándar,
y una crítica para mi equipo es que a veces se olvidan del contribuidor externo.
Dado que todos trabajan en una oficina a dos pasos de distancia,
es fácil olvidarse de arreglar o documentar algo que solo pasa la primera vez que descargás el proyecto.
Es usual ver personas frustradas por este tratamiento, pero es la única manera de mantener el buen nivel del código.
Es el mismo proceso de review que hacen entre los mismos desarrolladores internos.
El equipo suele mencionar PRs que tardaron mucho o problemas de comunicación cuando se hacen retrospectivas,
lo cual me demuestra su genuino interés en la participación de la comunidad.
Al principio puede resultar más sencillo codear uno mismo en lugar de hacer correcciones,
pero al hacer esto se logra que la comunidad se motive, que siga contribuyendo, y a largo plazo se gana mucho más.
---
# Conclusiones - 1
### OSS es win-win
Para la empresa porque
* Recibe mejor feedback
* Genera retención y participación
* Puede llegar a reducir sus equipos
y para el desarrollador porque
* Tiene más opciones
* Es más independiente
* Puede entender y extender sus herramientas
* Puede participar y opinar en la evolución
---
# Conclusiones - 2
### Por qué hacer OSS?
En lo personal
* Me encantó tener contacto directo con nuestros clientes
* El rol activo del dev en Open Source nos hace menos monos con teclado
Como dev en una empresa
* Es un trabajo con una dinámica muy distinta
* Tu trabajo tiene más visibilidad
Desde la comunidad
* Tu aporte mejora la experiencia de todos
* Los aportes de todos mejoran TU experiencia :)
* Es un círculo virtuoso
* Reportar bugs también es colaborar!
---
class: center, middle
# Muchas gracias!
???
Esto sería un pantallazo de cómo se trabaja OSS en Microsoft.
Es una empresa grande y otros proyectos como TypeScript pueden tener más para decir,
pero creo haber representado bien al menos a ASP.NET y EF.
</textarea>
<script src="https://remarkjs.com/downloads/remark-latest.min.js">
</script>
<script>
var slideshow = remark.create();
</script>
</body>
</html>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment