paint-brush
Como obter 16.000 estrelas do GitHub em menos de 2 anos 🚀por@medusajs
742 leituras
742 leituras

Como obter 16.000 estrelas do GitHub em menos de 2 anos 🚀

por Medusa6m2023/02/15
Read on Terminal Reader

Muito longo; Para ler

A Medusa visa redefinir a forma como o comércio eletrônico é construído. Com muita frequência, os desenvolvedores ficam presos a plataformas, abrindo caminho por meio de uma configuração sobre a qual têm pouca propriedade. Nossa missão é fornecer aos desenvolvedores os primitivos certos para construir, implantar e manter o comércio de maneira fácil e confiável. Queremos fornecer os blocos de construção arquitetônica para criar aplicativos de comércio sob medida e modularizados sem bloqueio de plataforma.
featured image - Como obter 16.000 estrelas do GitHub em menos de 2 anos 🚀
Medusa HackerNoon profile picture
0-item

10 lições sobre como chegamos a +16.000 estrelas do GitHub em 16 meses com a Medusa .


Faz apenas um ano e meio desde que abrimos totalmente o código da Medusa com a missão de construir o melhor mecanismo de comércio de sistema operacional para desenvolvedores com a Medusa.


Desde então, conseguimos reunir:

  • +25.000 projetos iniciados

  • +20.000 downloads npm mensais

  • +16.000 estrelas GH

  • +5.000 membros da comunidade

  • US$ 8 milhões em financiamento inicial


Abaixo estão algumas das minhas conclusões sobre como construímos uma forte tração inicial como um projeto de sistema operacional.


o que é Medusa

A Medusa visa redefinir a forma como o comércio eletrônico é construído. Com muita frequência, os desenvolvedores ficam presos a plataformas, abrindo caminho por meio de uma configuração sobre a qual têm pouca propriedade.


Nossa missão é fornecer aos desenvolvedores os primitivos certos para construir, implantar e manter o comércio de maneira fácil e confiável. Queremos fornecer os blocos de construção arquitetônicos para criar aplicativos de comércio sob medida e modularizados sem bloqueio de plataforma.


Repo: github.com/medusajs/medusa 🌟


TL;DR - 10 Lições de SO

Resolva um problema que dói

  1. Limpar ponto problemático do usuário : certifique-se de entender o ponto problemático do usuário que você está tentando resolver.
  2. Não há boas alternativas: o que você está construindo precisa ser claramente diferenciado do que já existe.
  3. Por que deve ser de código aberto: pergunte a si mesmo se uma solução de sistema operacional é necessária ou se soluções proprietárias realmente resolvem isso.


Crie uma experiência agradável com o produto

  1. Uma abordagem de produto focada: pode ser fácil se distrair, então continue focando em suas principais prioridades de produto.
  2. Apoie sua comunidade: para criar tração, você deve garantir que sua comunidade sinta seu compromisso com o sucesso dela.
  3. Invista em seu DevEx: facilite a introdução com o Docs, fluxos de integração rápidos e ferramentas de suporte.


Espalhe a palavra

  1. Facilite a compreensão: tenha uma descrição simples do produto pronta que facilite a compreensão do que você está construindo.
  2. Concentre-se nos canais de desenvolvimento: garanta que seu produto receba atenção em fóruns e blogs onde os desenvolvedores estão presentes.
  3. Faça grandes apostas e siga em frente: priorize eventos que você sabe que têm potencial para tornar seu produto viral e certifique-se de executá-los bem.
  4. Torne-o autêntico: crie conteúdo autêntico e útil para os desenvolvedores, em vez de mensagens de marketing regulares


Abaixo, irei me aprofundar um pouco mais em cada uma dessas etapas


Encontre um problema que dói

Seu projeto deve abordar um ponto problemático para os desenvolvedores que realmente são significativos para eles. Três coisas a serem observadas são:

  1. Esclarecer o ponto problemático do usuário: certifique-se de entender o ponto problemático do usuário que você está tentando resolver. No mundo do comércio eletrônico, sabíamos por experiência o quão dolorosa era a experiência do desenvolvedor com muitas ferramentas proprietárias (por exemplo, Shopify) e ferramentas legadas de código aberto (por exemplo, Magento e Woo). Todos eles são construídos com uma arquitetura monolítica completa, que força os desenvolvedores a buscar soluções alternativas hacky para personalizações e novas integrações. Tendo experimentado os pontos problemáticos de nossas carreiras anteriores, ficou mais fácil verificar se realmente havia um problema a resolver neste espaço.
  2. Não há boas alternativas: o que você está construindo precisa ser claramente diferenciado do que já existe. Em nossa opinião, o cenário do comércio eletrônico parecia ansiar por inovação. As soluções API-first, como Elasticpath, Commercetools, etc., pareciam se concentrar nas vendas corporativas e menos na experiência do desenvolvedor, enquanto sua natureza proprietária dificultava a oferta das mesmas opções de personalização de uma ferramenta de sistema operacional. No lado do código aberto, a maioria das soluções existentes oferecia back-ends baseados em PHP, mantendo-se fora do alcance dos desenvolvedores modernos, e ninguém havia acertado em cheio com uma alternativa baseada em JS ainda.
  3. Por que precisa ser de código aberto: pergunte a si mesmo se uma solução de sistema operacional é necessária no espaço ou se as soluções proprietárias realmente resolvem isso. Pode ser tentador supor que o código aberto é sempre o caminho a seguir, mas nem sempre é verdade. Com plataformas de comércio eletrônico, a complicação é que as necessidades do usuário variam muito para diferentes tipos de negócios (por exemplo, apenas de atender clientes B2C a B2B) e isso significa que uma solução proprietária única raramente é o caminho certo quando um caso de uso é um pouco fora da caixa - o que explica por que mais da metade dos maiores sites de comércio eletrônico do mundo ainda são construídos com back-ends de comércio personalizados ou de código aberto.


Crie uma experiência agradável com o produto

Identificar o problema não é apenas suficiente. Construir um produto para resolvê-lo e investir na comunidade e no DevEx em torno dele também é fundamental.

  1. Uma abordagem de produto focada: pode ser fácil se distrair, portanto, mantenha o foco nas principais prioridades do produto. Construindo código aberto, a comunidade terá muitas opiniões sobre recursos adicionais, plugins ou funcionalidades a serem construídas. Parte desse feedback será menos relevante para seu público principal. Portanto, seja seletivo quanto às entradas que você obtém e crie os poucos recursos que causarão um impacto significativo para o seu público principal, em vez de muitos recursos meio decentes para todos.
  2. Apoie sua comunidade: Para criar tração, você deve garantir que sua comunidade sinta seu compromisso com o sucesso dela. Desde nossos primeiros dias, temos sido extremamente focados em nossa comunidade. Fazemos isso por meio de uma ampla gama de atividades, desde eventos da comunidade até nossas discussões transparentes sobre produtos e nosso foco contínuo na criação de materiais de apoio à comunidade. Da mesma forma, estamos dedicando muito tempo para responder às perguntas da comunidade no GitHub e no Discord, ajudando os desenvolvedores a começar.
  3. Invista em seu DevEx: facilite a introdução com o Docs, fluxos de integração rápidos e ferramentas de suporte. Priorizamos a experiência do desenvolvedor colocando muito foco em áreas como nossa Documentação - que tratamos como um produto próprio com um membro da equipe em tempo integral dedicado a ela - enquanto garantimos que nosso fluxo de integração seja fácil de realizar com suporte a modelos iniciais de projeto.


Espalhe a palavra

Quando você tem uma ótima experiência de desenvolvedor configurada, sua principal tarefa passa a ser criar consciência em torno do projeto.

  1. Facilite a compreensão: tenha uma descrição simples do produto pronta que facilite a compreensão do que você está construindo. Concentramos muito de nossas mensagens em ser "a alternativa de código aberto do Shopify", que ressoou instantaneamente com os desenvolvedores (veja, por exemplo, nosso lançamento do HN). Na realidade, a Medusa é muito mais do que o Shopify de código aberto, pois nossa arquitetura modular se adapta melhor a casos de comércio eletrônico mais personalizados do que às lojas típicas do Shopify "mãe e papai". No entanto, a simplicidade da mensagem tornou fácil para os desenvolvedores categorizar a solução ao ouvi-la rapidamente pela primeira vez.
  2. Concentre-se nos canais de desenvolvimento: garanta que seu produto receba atenção em fóruns e blogs onde os desenvolvedores estão presentes. Sempre nos mantivemos focados em canais de desenvolvedores e gastamos energia criando conteúdo e iniciativas para direcioná-los; por exemplo, aproveitando o Reddit para fazer muitos "minilançamentos" ou configurando um programa de escritores para produzir conteúdo para canais como Dev.to , Medium e Hashnode. Outras ferramentas como Supabase se concentram no Twitter, enquanto o Digital Ocean é um excelente exemplo de conteúdo de canal próprio bem feito.
  3. Faça grandes apostas e siga em frente: priorize eventos que você sabe que têm potencial para tornar seu produto viral e certifique-se de executá-los bem. De vez em quando, temos eventos que acreditamos ter o potencial de tornar a Medusa viral, por exemplo, lançamento do ProductHunt, anúncio de investimento em série Seed ou nosso recente Medusa Hackathon. Para todos eles, priorizamos o planejamento antecipado e a criação de uma campanha estruturada para garantir a exposição máxima, às vezes preparando vídeos, conteúdo de anúncio e atualizações do site com semanas ou meses de antecedência.
  4. 10) Torne-o autêntico: crie conteúdo autêntico e útil para os desenvolvedores, em vez de mensagens de marketing regulares. Desde o início, não gastamos um único dólar em anúncios para a Medusa. Em vez disso, concentramos nossos recursos na criação de conteúdo que fosse autêntico para os desenvolvedores por meio de artigos e tutoriais centrados em explicar o que nosso produto fazia, em vez de mensagens mais voltadas para vendas.

Uma palavra de cautela

Espero que o que foi dito acima tenha fornecido algumas contribuições úteis de nossa jornada.


Um último aviso: com toda a honestidade, as estrelas do GH podem ser uma medida de vaidade para a popularidade de um projeto quando usado como uma métrica autônoma.


Serei um defensor da análise de mais métricas relacionadas ao uso, como início de projetos, desenvolvedores ativos, contribuidores mensais, etc.


Onde as estrelas do GitHub servem como um bom indicador é entender se as pessoas estão interessadas no que você está construindo - e é uma das poucas métricas de sistema operacional comparáveis entre os projetos.


Uma versão deste artigo aparece aqui .