Liberar un proyecto de código abierto sin avergonzarse [cerrado]

A menos que el proyecto esté dirigido a desarrolladores (por ejemplo: un marco de desarrollo, en cuyo caso QUIERES que lo critiquen si te hace aprender aún más), no debes preocuparte. Pero incluso entonces, hay muchos proyectos de código abierto dirigidos a desarrolladores que son basura, pero la gente los ama porque van al grano (piense en Codeigniter, que está muy mal diseñado y, sin embargo, es el marco PHP más popular)

Si es una aplicación para humanos normales, probablemente solo se preocuparán por los resultados.

Tu código tiene problemas. También el mio. ¿Alguien más responde a esta pregunta? Su código también tiene problemas.

A menos que sea, digamos, 10 líneas o menos, tiene fallas. Tal vez trágicamente.

Ser un desarrollador es unirte CONSTANTEMENTE contra los límites de tus habilidades y comprensión. Puede que no sea así para TODOS los desarrolladores, pero para mí y para los que conozco, trabajamos casi al límite de nuestra competencia en todo momento. Y enfrentas eso una y otra vez, luego tienes un buen fin de semana, luego regresas el lunes y hazlo una y otra vez.

Después de haber trabajado esa vida durante 15 años, lo que he decidido es este hecho: Usted no es su código . Usted escribe el código. La sentencia del código NO es una sentencia de usted . Tu código tiene problemas, algunos de los cuales sabes, otros que no. Haber llamado tu atención sobre te ayuda , a menos que lo único que puedas hacer al respecto es sentirte mal. Sentirse mal no mejora tu código, solo te hace sentir mal.

Usted escribe su código, y lo escribe tan bien como usted sabe. Tal vez mañana sepa más que hoy, pero hoy lo hizo tan bien como sabía. Mi consejo es: escriba el código de hoy hoy y el código de mañana mañana. Luego, tenga un buen fin de semana y regrese el lunes para escribir el código del lunes.

Como regla general, los programas de código abierto tienen tres grupos de personas que consultan el código fuente.

1. Las personas que están considerando modificar el código para hacer que el programa funcione de manera ligeramente diferente para ellos, para trasladarlo a una plataforma diferente, o como un punto de partida para sus propios programas. Si no les gusta el código, normalmente no lo usarán, y nunca escuchará de ellos.
2. Estudiantes, intentando aprender a codificar en el idioma que usaste. Casi nunca se pondrán en contacto con usted, pero ocasionalmente puede recibir un correo electrónico preguntando por qué hizo algo de una manera en comparación con otra. (Para ser justos, no he recibido uno de estos correos electrónicos en muchos años. Creo que los sitios web como StackExchange pueden haber reemplazado esta interacción)
3. Investigadores de seguridad, como los chicos de OpenBSD, que intentan decidir si su herramienta es lo suficientemente segura como para incluirla en su distribución. Si no lo es, pero aún así quieren incluir su programa, entonces estarán en contacto para encontrar una manera de protegerlo. (Y si su programa se vuelve popular, me imagino que probablemente también atraerá a los investigadores de Black Hat, quienes no se pondrán en contacto con usted sin importar lo que encuentren).

En el mundo real, la gente realmente no leerá su código fuente por ninguna otra razón que no sea esta, porque simplemente no es necesario. Antes solo recibías tal cantidad de comentarios porque publicaste el código en un foro, lo que implicaba que querías recibir comentarios sobre el código.

No creo que realmente debas preocuparte por un torrente de abusos; las únicas personas que pueden contactarte son las personas que desean agregar funciones o corregir errores, que ya han buscado en el código base y no han corrido gritando por las colinas. ;)

Realmente no entiendo la psicología detrás de esta pregunta ... una mejor pregunta para preguntarte sería "qué tengo que perder al lanzar este software"

Incluso si su proyecto está lleno de olores de código, ¿tiene que perder algo?

Incluso si el código es horrible y alguien se toma el tiempo de escribirte un mensaje de correo electrónico, adivina qué, probablemente usó tu software lo suficiente como para querer hacerle algunos cambios y hacerlo mejor.

¡Deberías estar feliz por eso! Acepte las críticas y mejore su código, pídale al chico enojado que se tomó el tiempo de escribirle. ¡A él le importa!

Después de un tiempo, los mensajes de correo electrónico se detendrán, la gente seguirá utilizando su software, habrá aprendido de sus errores y las lagunas que no sabía que existían en su educación ya no estarán disponibles.

Prefiero trabajar con alguien que esté dispuesto a hacer algo, admitir sus errores, corregirlos y seguir adelante que alguien que no esté dispuesto a hacer nada.

Si realmente no se siente cómodo al lanzar el software bajo su nombre, entonces libérelo bajo un apodo. Si tiene éxito, consíguelo como tuyo, si no cambias tu apodo :)

Soy un firme creyente, no solo en el código abierto, sino en desarrollo abierto , donde las personas pueden ver la evolución completa de su código. Desde el prototipo del cerebro hasta el código de trabajo ... nunca se debe avergonzar. Te estás poniendo ahí afuera, eso toma agallas. Poseerlo y estar orgulloso de ello. Nadie es perfecto.

Cuanto más tiempo he estado en este juego, más me he dado cuenta de que la única medida de la calidad del código es la experiencia del cliente. Si estás escribiendo una función, es la persona que llama a esa función. ¿Una biblioteca? Los desarrolladores que escriben para esa biblioteca. ¿Un marco? Los adoptantes de la misma. Un independiente? La persona o demonio que inicia el programa.

El código de Niza tiene su virtud, no me malinterpretes, pero cuando se dice y se hace, la única medida es "¿Funciona?" He visto un montón de código limpio que es un lío con errores, y un montón de código satánico trastornado que es completamente confiable (además de bueno limpio y mal feo también :))

Entonces, si los críticos dicen que tu código es feo, a quién le importa. Si dicen que no funciona, esa es la crítica útil (¡datos de prueba!) Que busca mejorar su programa. ¡Aguanta ahí, evita la población de trolls de Internet y diviértete en tu proyecto!

Estoy totalmente de acuerdo con lo que han dicho otros carteles: incluso si su código es malo y no es de alta calidad, a la mayoría de las personas simplemente no les importa. Todos los que han buceado en el código de OpenSource en un momento u otro pueden haber pensado para sí mismo que "WTF sucedió aquí".

Pero no conozco a nadie por ahí con la motivación para criticar la base de código de un proyecto por el simple hecho de decir "amigo, ¡tu código se ve horrible!". Todos hemos estado allí y todos sabemos que cualquier código que estemos escribiendo ahora nos parecerá bastante aburrido en solo unos pocos feeks (el mío definitivamente lo hará).

Así que no te preocupes tanto: la gente simplemente tiene mucho mejor que hacer en su tiempo libre que con el código de los proyectos OpenSource.

El código real siempre se está pudriendo y está sucio, pegado y mantenido de manera aproximadamente ad hoc. La limpieza se limita a documentar casos especiales y constantes especiales. Existe una discrepancia de impedancia entre el código limpio y el mundo real.

También me he dado cuenta de que cualquier ingeniero competente puede separar el código de otra persona.

Si (1) pasa las pruebas y hace el propósito sin fallar Y (2) puedes hacer cambios menores con solo reescribir de forma menor, es un buen código.

Algunas palabras sabias de Reid Hoffman, cofundador de LinkedIn:

  

"Si no estás avergonzado por el primer lanzamiento de tu producto, lo has hecho demasiado tarde".

     

"Lograr el compromiso con los miembros y ver qué es realmente importante es completamente clave ... Por lo tanto, obtiene el producto mínimo viable tan pronto como pueda".

Creo que esto se aplica especialmente a los proyectos de código abierto donde tener una gran idea con un comienzo prometedor alienta a las personas a contribuir y participar. Algo que está tan pulido que te hace ponerte las gafas de sol puede no evocar tales sentimientos. Pero lo más importante acerca de la publicación temprana es destruir todas tus ideas preconcebidas sobre lo que se debe hacer y comenzar a moverte en la dirección correcta.

¿Quién eres? ¿Es usted alguien a quien las personas conocen como el programador de Dios y le preocupa que su reputación disminuya? ¿Es usted quien solicitará el trabajo y le preocupa que el empleador pueda leer estas críticas y piense que es un mal programador? Lo que pregunto es por qué tienes miedo de las críticas sobre cómo cagas. Tienes la oportunidad de decidir cuáles son los comentarios genuinos y cuáles son las críticas. Tome los buenos como defectos y corríjalos en la próxima versión. Solo siento que te preocupas innecesariamente por las críticas. Usted está ayudando a la comunidad de código abierto, que en sí misma es una muy buena causa. Por favor, sigan el buen trabajo.

Si está realmente preocupado, simplemente use un seudónimo en línea al lanzar el software. Entonces no hay forma de que afecte tu reputación en la vida real.

Cuando / Si recibes críticas públicas, esto te llevará a mejoras en el código y te ayudará a crecer como desarrollador. Eso es algo bueno.

Creo que para mis proyectos, la mayoría de las críticas / sugerencias constructivas se envían de forma privada en lugar de emitirse públicamente, y aún así es poco probable que reciba una avalancha de comentarios. Por lo tanto, recomiendo ir solo por ello!

Buena suerte.

No hay nada malo con el autoestudio en sí mismo. No se puede aislar y las revisiones de código de pares pueden ayudar con eso.

También debes centrarte en lo que estás haciendo. ¿Por qué te importa si recibes comentarios negativos sobre tu trabajo? Si es porque está asumiendo que si recibe críticas es porque el código es malo o no es bueno para la programación, eso puede ser cierto o no.

El propósito del esfuerzo es asegurarse de que el código funcione y obtener el mejor código posible, pero a partir de la experiencia práctica, tampoco todo el código comercial es estelar. A veces tienes malos requisitos, a veces no tienes tiempo para hacerlo bien. A veces, los desarrolladores quieren mostrarse geniales al hacer que otros se vean mal.

No creo que puedas aprender sin cometer algunos errores, especialmente si es algo que requiere verdadera disciplina y esfuerzo. Si fuera fácil, todos lo estarían haciendo. Solo intente limitar los errores a los menores, utilizando las mejores prácticas establecidas. ¡Me doy cuenta de que eso no siempre es posible!

Si me preocupara lo que otros pensaban de mí como programador, en primer lugar no habría entrado al campo. Dicho esto, mi primera crítica al código es: tratar de tomarlo objetivamente y aprender de él.