¿Alguna vez han pensado en crear un mercado para plugins y temas?
Razones de esta pregunta
Discourse permite a los desarrolladores crear temas y plugins. Esto es muy interesante. Mi pregunta sería si existe un mercado para plugins y temas de pago dentro de Discourse. Por ejemplo, me gustaría crear temas y plugins de pago. Porque podría recibir dinero por los plugins y temas que desarrollo para Discourse. Un gran ejemplo de esto es Themeforest, puedes crear un sitio web y si a alguien le gusta tu sitio web, ganas dinero vendiendo ese sitio web específico en Themeforest.
En mi caso, vendería mis plugins y temas dentro de Discourse a clientes o empresas específicas. La ventaja que creo que es buena para esta idea es que puede animar a más desarrolladores a crear más plugins y temas para Discourse, así como a integrar más servicios, empresas y clientes. En otras palabras, es solo otra forma de hacer que Discourse sea aún más viable, lo cual ya es algo interesante, relevante y consolidado. Otra gran ventaja de un mercado es el hecho de que obtienes un porcentaje de dinero del desarrollador de ese plugin o tema dentro de la propia plataforma.
Algunos desarrolladores pueden pensar que esto es bueno o no interesante. Porque dependiendo del porcentaje, a veces es malo para ti desarrollar algo y recibir muy poco. Sobre esto, como dije, hay quienes lo apoyan y hay quienes piensan que el mercado no es algo bueno o viable.
Creo que para desarrolladores como yo que están empezando en el campo de la tecnología de la información, es mejor desarrollar plugins y temas para algo que ya existe y está consolidado como Discourse que hacer algo nuevo y desde cero. Porque normalmente lleva mucho tiempo y mucha investigación y marketing para que esto funcione, para que sea financieramente viable. Además, normalmente tendrías que ganarte a clientes y empresas, y eso también lleva tiempo. Además de la credibilidad, la reputación y la marca que construyes.
Normalmente, las personas a las que no les gustan los mercados son desarrolladores que quieren o tienen la necesidad de tener un negocio. Sobre estos desarrolladores, nada les impide crear un sitio web con temas y plugins para Discourse específicos para empresas y clientes con los que tienen contacto y necesitan ganar más dinero del que ganarían en el mercado central, por así decirlo.
Muchos proyectos de código abierto que he conocido e investigado tienen un modelo de negocio de suscripción. Normalmente, en estos casos, existe lo que llamamos un tipo de plan. Estos suelen ser estos 3 planes: comunidad, empresa, negocio. El plan comunitario generalmente no tiene soporte técnico para los clientes y es gratuito. Enterprise es el plan que da soporte a los clientes y es de pago. El plan de negocios suele ser para grandes empresas y es negociable y de pago. No sé cómo funciona el modelo de negocio de Discourse, pero creo que por lo que he visto en el sitio principal, es el modelo de suscripción. Puedo estar equivocado y, si es así, me disculpo.
Un modelo de suscripción es un tipo de modelo de negocio. Por lo tanto, las empresas que optan por este tipo de modelo de negocio (es decir, el modelo de suscripción) suelen querer o pensar en tener un mercado. Un buen ejemplo de esto es Themeforest, en el pasado simplemente creabas sitios web y ponías el enlace de pago allí, así que si a alguien le interesaba tu sitio web, lo vendías y ganabas dinero. Hoy en día en Themeforest también puedes crear plugins y venderlos allí. Es algo que creo que es realmente genial e interesante, como modelo de negocio.
Como dije antes, es solo una visión general de lo que creo que sería interesante como desarrollador. Además, veo el mercado como algo que puede habilitar proyectos de código abierto. Por la razón principal de que podemos ganar dinero con plugins y temas específicos para los clientes que atendemos. Este es un escenario muy ideal y creo que es interesante porque da a los desarrolladores más libertad para seguir utilizando este software. Además, aumenta las integraciones con más software.
Notas
Si alguien puede leer y discutir cualquier punto de vista a favor o en contra, agradecería sus comentarios.
No estoy criticando el modelo de negocio de Discourse.
Creo que si el valor porcentual de los plugins y temas de pago no es demasiado malo (demasiado caro), sería un gran comienzo para el Mercado de Discourse.
Cité el ejemplo de Themeforest, pero hay varias empresas que utilizan el modelo de suscripción con mercado, como Google. Muchos productos de Google son modelos de suscripción y tienen un mercado, un ejemplo de esto es Google Docs.
Hablé de ThemeForest o Google o Google Docs, solo para citar un ejemplo real de un negocio con suscripción y mercado juntos, mi objetivo no es promocionar nada, solo lo mencioné como algo de referencia.
También pensé en esto. Quizás todas las personas interesadas en el desarrollo de plugins de Discourse deberían unirse y construir un mercado sin comisiones con criptomonedas. Solo necesitamos una forma de dar acceso privado a los repositorios de GitHub. Podríamos alojar una instancia de Gitea y construir una “puerta de criptomonedas” delante de los repositorios.
El modelo más utilizado aquí son los plugins y temas personalizados de pago y los plugins de código abierto que otorgan credibilidad al desarrollador (y desarrollo de habilidades). A veces, un plugin que se desarrolla para un cliente en particular se lanzará como código abierto.
Aquellos que buscan ayuda pueden publicar en Marketplace. Es raro, pero también puedes ofrecer servicios en Marketplace.
demasiado problema para otorgar y revocar acceso y administrar pagos significa que necesita cobrar precios altos y no puede vender en volumen/mercado a audiencias más grandes.
Pensé en la siguiente solución simple que podría ayudar en este caso: podemos pedir que los complementos se envíen como un archivo zip con contraseña. El servidor solo tendría que descomprimir el archivo e instalar el complemento en Discourse. La contraseña podría ser una clave cifrada que la persona crea para instalar.
De este modo, solo se descomprimirá con una clave. La clave solo descomprime el archivo después de que se haya realizado el pago. Ahora, este escenario funciona tanto para complementos de pago como para complementos de código abierto, depende del desarrollador.
Si el problema es visualizar el código fuente, una forma es usar un Ofuscador. Cuando el código se ha enviado al repositorio, pasa por un proceso de ofuscación, donde este código se envuelve y solo se puede ver con una clave de desarrollador específica.
La solución que describo sería similar a lo que tendrías con flatpack en ubuntu, que es un paquete que descargas e instalas en ubuntu sin necesidad de instalarlo necesariamente a través de la línea de comandos, flatpack sería como un archivo ejecutable donde solo tienes que hacer clic en siguiente, siguiente como en Windows.
Para mapear los repositorios, podemos usar la API de Github para eso; esto solo funcionaría para complementos que estén alojados en Github y que sean públicos. Github tiene una API donde puedes buscar repositorios por etiqueta.
Otra forma sería usar un rastreador web aquí para mapear posibles repositorios de pago. Simplemente no sé si el rastreador web cumple con los términos de licencia de privacidad y seguridad de Discourse. Como comentar y pude leer todos los comentarios, si publicas en el hashtag #marketplace, generalmente son complementos de pago en Discourse donde puedes mostrárselo al mundo.
En resumen, creo que los desarrolladores pueden, en teoría, publicar el enlace a estos repositorios directamente en el sitio donde alojan el archivo zip. Luego, el webscraper toma el enlace a través de las etiquetas marketplace y muestra los complementos en la categoría de pago. Si deseas instalar el complemento de pago, una forma sería pagar, así se libera el zip y después de ser liberado, el zip se descomprime con la clave de activación que se genera después del pago.
Para que esta solución sea elegante, podemos hacer algo como .discoursepack.
La extensión .discoursepack es una extensión del formato zip personalizado, es el formato para instalar el complemento en Discourse.
El servidor almacena archivos discoursepack durante un período de tiempo
Para instalar el complemento de pago en Discourse es necesario descomprimir el archivo discoursepack con la contraseña que recibió al realizar el pago.
Sin la clave de cifrado no es posible crear el archivo discoursepack. Al igual que no es posible abrir o leer este tipo de archivo discoursepack.
Los complementos de pago se pueden alojar en el propio servidor de Discourse o se pueden alojar en el servidor del fabricante del complemento.
Los complementos abiertos se pueden alojar en Github.
Si los complementos de código abierto no están alojados en github y no son públicos, una solución viable es requerir el enlace donde se encuentra el archivo discoursepack.
Si son complementos de pago, estos complementos no están alojados en Discourse. En este caso, como están alojados en el sitio web del fabricante, es necesario que el fabricante presente el enlace directo a este archivo a través de una clave que solo él conoce y que es temporal para todos los medios de pago.
Si tienes un gran volumen de complementos para subir a Discourse, recomiendo el CMS Cockpit, que es ligero y no debería pesar demasiado.
complemento de código abierto config.yml
server:
host: 127.0.0.1
port: 8006
debug: true
analytics:
enabled: true
tag: xx-xxxxx-xxx
plugin:
title: authmatic-example
type: public, paid # o public, nopaid
description: authmatic-example de un desarrollador que hace cosas. Impulsado por la empresa authmatic-example.
url: https://github.com/authmatic-example/releases/v1/authmatic-example.discoursepack
releases: v1
author:
name: authmatic-example
github: authmatic-example
twitter: authmatic-example
site: authmatic-example.com
avatar: /assets/avatar.jpg
keystore:
enabled: true
client_id: xxxxxxxxxxxxxxxxxxxxxxxxx
client_secret: xxxxxxxxxxxxxxxxxxxxxxxxx
repo: authmatic-example
owner: authmatic-example
admins: [authmatic-example]
log: true
format: text
level: info
line: true
complemento de código cerrado config.yml
server:
host: 127.0.0.1
port: 8006
debug: true
analytics:
enabled: true
tag: xx-xxxxx-xxx
plugin:
title: authmatic-example
type: private, paid
description: authmatic-example de un desarrollador que hace cosas. Impulsado por la empresa authmatic-example.
url: client_url_temp
releases: v1
author:
name: authmatic-example
github: authmatic-example
twitter: authmatic-example
site: authmatic-example.com
avatar: /assets/avatar.jpg
keystore:
enabled: true
client_id: xxxxxxxxxxxxxxxxxxxxxxxxx
client_secret: xxxxxxxxxxxxxxxxxxxxxxxxx
client_url_temp: xxxxxxxxxxxxxxxxxxxxxxxxx
repo: authmatic-example
owner: authmatic-example
admins: [authmatic-example]
log: true
format: text
level: info
line: true
Tengo la sensación de que estás intentando resolver un problema que no existe y estás tirando al niño con el agua del baño.
Tu solución no permite una fácil actualización, es difícil/imposible de usar en despliegues automatizados y es fácil de eludir.
Las claves de despliegue y un repositorio Git serán suficientes y no tendrán los inconvenientes mencionados.
De nuevo, mi consejo: valida tu modelo de negocio primero y céntrate en el valor. Primero haz un plugin que todo el mundo quiera comprar, luego resuelve el problema de cómo venderlo.
Es solo una ligera exageración sugerir que nadie en el planeta pagaría por un plugin que no podría instalar un plugin que es un zip cifrado.
Tengo una plataforma que podría instalar plugins utilizando claves de despliegue en sitios que administra.
Otra solución sería hacer que el plugin esté disponible públicamente, pero que llame a casa para ver si alguna licencia es válida. Podría ser fácilmente engañado por alguien que edite el código, pero creo que así es como funcionan muchos plugins de WordPress.
