2
caiobarroso
1 min de leitura ·

Como fazer uma nova ferramenta open source competir com as gigantes?

Estou construindo uma plataforma open source pra React Native e percebi que meu maior desafio talvez nem seja o código

É fazer alguém trocar o que já funciona

Hoje já existem Flipper, Reactotron, RN DevTools, Rozenite… ferramentas conhecidas e amplamente usadas. Mesmo que eu construa algo muito bom, por que um dev sairia da zona de conforto pra testar outra?

Tenho postado quase todo dia no Reddit, conversado com devs, pegado feedback e implementado algumas sugestões. Já postei aqui no TabNews também e hoje o projeto está com 42 estrelas no GitHub

Pra dar contexto, o projeto é o NativeScope. É uma plataforma de debugging open source pra React Native, com módulos de Storage, Network, Logs e uma Timeline que conecta os eventos. A ideia é ir construindo os módulos em cima de dores que encontro usando as ferramentas atuais e, principalmente, do feedback de outros devs

GitHub: https://github.com/caiobarroso/react-native-nativescope
Website: https://www.nativescope.dev/

Mas a dúvida que mais fica pra mim é

como uma ferramenta nova conquista espaço quando as pessoas já têm uma solução que conhecem e confiam?

Pra quem já passou por isso no open source, o que realmente fez diferença? E o que faria você trocar uma ferramenta estabelecida por uma nova?

Carregando publicação patrocinada...
2

Depende muito. Eu particularmente me afastei desse ecosistema a anos e não sei como esta atualmente. Então darei um ponto de vista geral.

Sua ferramenta resolve o mesmo problema que outras? Então qual é o diferencial dela?

Vamos comparar o Node com o Bun. Ambos são runtime. Node é amplamente utilizado a nível global. É um projeto de peso, amplamente testado. No Node conta com uma base de código antiga, que não evoluiu muito bem ao longo do tempo - prevenindo uma modernização.

Agora temos o Bun, que não substitui o Node (ainda), mas chegou como uma alternativa completamente nova com resultados reais. Isto fazia praticamente o mesmo que Node, só que melhor, mais rápido e contava com mais features essenciais. Apesar disto, Bun tem seus trade-offs em relação ao Node.

São ferramentas que resolvem o mesmo problema, mas o Bun ganhou uma comunidade fiel, e é sem dúvida a opção padrão para novos projetos.

Sua ferramenta se encontra nessa mesma situação? Se sim, exponha o que ela faz. Ande em comunidades mostrando o potencial. Faça seu marketing. Compare e mostre o seu valor.

Sua ferramenta resolve algo novo? Demonstre o valor dessa ferramenta com dados práticos. Por que escolher esta ferramenta? Qual problema resolve? Onde isso se encaixa? Para quem serve?

Enfim, o valor de uma ferramenta depende inteiramente da sua utilidade. Se é uma dor real, pessoas adotaram (mas precisam saber que existe)

1

Vou te mostrar a minha visão, eu vou falar em venda porque mesmo voce dando de graça, você esta vendendo a ideia.

Vender para programador é um dos piores mercados do mundo, mesmo que seja opensource. Pense no seguinte esse mercado equivale a vender uma ferramenta de madeira pra um marceneiro. O Marceneiro pensa, ja tenho minhas ferramentas de metal aqui, pra que comprar uma de madeira que eu mesmo posso construir? Resposta a essa pergunta = Só se a ferramenta é complexa o suficiente para eu não querer fazer e útil o suficiente em várias camadas para valer apena, porque se apenas um pedaço simples dela é util eu construo apenas aquele pedaço. Entendeu a lógica? A ferramenta de metal ai você pode encarar como as não fácilmente modificáveis, tipo um VScode, entendeu, ele é adaptável, mas modificar o cerne dele é outra história. Além disso, como o programador sabe o valor dela? 99% do mercado não vai pesquisar sua ferramenta para descobrir, vai iguinorar porque é o mais simples, você precisa mastigar tudo e entregar de forma clara: É melhor nisso e nisso contra x concorrente(s).

1

...o que faria você trocar uma ferramenta estabelecida por uma nova ?

Nao sou eu que tenho de dizer isso, eh voce.

Veja, se voce esta criando uma ferramenta (seja paga, gratuita, proprietaria, free software ou open source), eh voce que tem de indicar os beneficios que ela possui em relacao as demais.

No caso, o que ela entrega como novo/extra em relacao a outros debugs precisa ser visivelmente melhor que a solucao que ja esteja em uso.

  • O Flipper foi descontinuado (e era pesado)

  • Reactotron eh otimo, mas precisa de config manual e nem sempre correlaciona eventos de forma fluida

  • etc

O primeiro passo eh esse.

Falando como se fosse um SaaS: qual o ICP (o publico alvo) do seu projeto ? Nao adianta ser generico aqui (DEV) mas especifico (p.ex. o que fez voce criar a ferramenta ? Por que nao usa o que ja existe ? O que outros DEVs tem de semelhanca contigo ?)

Por exemplo: eu uso o OmniRoute como AI gateway porque ele eh mais completo que os outros e entrega coisas que eu preciso (como COMBOS de conta gratis para uso com agentes). O que voce entrega que vale a pena ?

Saude e Sucesso !

1

No meu caso, o NativeScope é open source e 100% gratuito e nasceu justamente de coisas que eu sentia falta usando Flipper, Reactotron, DevTools, Rozenite, etc....

Trabalho com apps offline first e muito dado local. Sempre tive dificuldade pra inspecionar JSONs gigantes, ficar abrindo chave por chave, e principalmente lidar com GBs de SQLite, MMKV e AsyncStorage sem gargalo. Acabei criando uma forma diferente de visualizar e navegar nesses dados e hoje sinceramente só uso ela.

A partir daí fui levando a mesma ideia pro resto. Network, Logs, Timeline… basicamente features que eu sentia falta nas ferramentas que já usava, junto com sugestões que outros devs estão me dando.

Hoje essa lib simplesmente virou minha principal ferramenta de debugging no trabalho. Não por ter sido eu que fiz, mas porque resolve exatamente as coisas que me incomodavam antes tlgd

Agradeço demais pelo feedback mano, TMJ!

1

Pegando carona na resposta do @Programmer404, estes dias precisei escolher entre o "forgejo" e o "gitea" para um projeto de github privado self-hosted.

O que me ajudou na decisao foi justamente "papers" comparando cada um lado a lado e explicando os pontos fortes e fracos, os trade-offs, etc.

Teu "Why NativeScope" ate fala algumas coisas, mas voce precisa explicitar melhor como estas coisas sao diferentes do concorrente e porque tua opcao eh melhor.

Colocando de outra forma: esquecendo um pouco quem ja usa, se um DEV que nunca usou antes um debug react caisse no teu github, como ele iria diferenciar tua ferramenta de outra que eh muito mais utilizada e saber que eh melhor ?

Nao eh uma questao de falar mal (ok, um pouquinho so), mas ser claro naquilo que voce eh superior.

Saude e Sucesso !