# OSPOs, ISPOs, Developer Advocacy

*(Viene de https://devrel-espana.slack.com/archives/C9C56N8TS/p1672921717344929)*

- Developer Advocate como _rol_ (debatible)
- Por ejemplo, DevOps es una *práctica* o una *cultura*, no un rol
- Una de las actividades más relevantes: relaciones para un componente open source o una plataforma extendible por desarrolladores a través de SDKs abiertos que interactúan con APIs
- Otra actividad: DevRel para "employer brand" https://dev.to/juliamurashova/evolution-of-developer-relations-how-devrel-helps-to-build-an-employer-brand-3fko para proyectar una cultura de desarrollo "molona" hacia el exterior con el objetivo de atraer talento
- De hecho David Gómez cuenta que fue su primera experiencia, antes de llamarse "advocate"
- Otra rama: "internal devrel", podría formar parte de una OSPO o ISPO (seguir leyendo)
- [OSPO](https://ospomindmap.todogroup.org/) (Open Source Programs Offices)
- Una OSPO es un _equipo_ o _estructura_, normalmente _transversal_
- La primera, creada en Google por Chris DiBona https://opensource.com/business/16/5/whats-open-source-program-office
- Quien por cierto fue despedido en los despidos masivos de enero de 2023
- Originaron Google Code y Google Summer of Code
- Inbound (consumir open source) + Outbound (contribuir a open source) https://opensource.com/article/20/5/open-source-program-office
- En definitiva, la estrategia open source, hacia dentro y hacia fuera
- Si bien, RedHat da una definición alternativa: "an OSPO's role is to align the efforts of all relevant parts of an organization—engineering, sales, marketing, content creation—toward making open source methodologies and outputs successful" https://www.redhat.com/en/blog/what-does-open-source-program-office-do que se podría parecer más a una ISPO
- JHU: "a construct used [...] to organize and coordinate open source program activity within an organization and to engage with the broader community" https://drcc.library.jhu.edu/open-source-programs-office/
- Roles típicos: "developer education", "community engagement" y "open source adviser"
- Para una organización con cultura interna de open source, una OSPO no tiene tanto sentido y merece la pena comunicar hacia el exterior
- Un DevRel/Developer Advocate podría trabajar en una OSPO
- ISPO ([Inner Source](https://www.wikiwand.com/en/Inner_source) Program Offices)
- También un equipo
- Recordemos: implementar una "cultura open source" en organizaciones que no la tienen
- Según algunas definiciones, añadiría una tercera pata a lo que hace una OSPO: hacer que haya circulación interna de open source (es decir: open source que se produzca _y_ se consuma en la empresa)
- Parece claro que podría haber OSPO sin ISPO
- Teóricamente, también podría haber ISPO sin OSPO: no se publica externamente ni se consume open source externo: solo se consume open source _creado en casa_. La frontera con el exterior es impermeable.
- Esto podría crear efectos divertidos como https://calpaterson.com/bank-python.html
- Viendo las definiciones alternativas de arriba, me inclino a pensar más en algo que se enmarcaría dentro de una OSPO
- Resumen OSPO vs ISPO:
- Open source **externo** que se consume *internamente*: OSPO (inbound)
- Open source **externo** al que se contribuye *desde dentro*: OSPO (outbound)
- Open source **interno** que se libera *externamente*: OSPO (outbound)
- Open source **interno** que se consume *internamente*: ISPO (innerbound)
- Resumen DevRel vs OSPO/ISPO:
- Una *persona* DevRel puede trabajar en un *equipo* de Developer Experience (https://milendyankov.com/blog/2022/02/from_devrel_to_developer_experience/), una OSPO, o una ISPO