10 razones para escoger un proyecto

Algunas razones que me llevan a preferir trabajar con un proyecto u otro.

Joseph Edward Southall

archivado en: Internet / 7 enero, 2016

En un artículo reciente titulado Why I'm not using your open source project, Nicholas C. Zakas, explica las razones que le llevan a decantarse por un proyecto u otro, entendiendo por proyecto un frame, librería, plugin o lo que sea de terceros. Si se entiende inglés vale la pena leer el original; en caso contrario, este es un resumen de sus argumentos.

1. El proyecto carece de licencia. El hecho que no tenga licencia no implica necesariamente que se pueda usar con libertad, incluida la modificación del código, sino que se encuentra en una especie de limbo legal que puede terminar siendo problemático.

2. La licencia tiene restricciones que dificulten la adecuación del código a tus necesidades, como el no poder cambiarlo a tu antojo. Es el caso, explica, de las licencias GPL/LGPL.

3. El proyecto no se mantiene en la actualidad. Basta con ver la fecha de los últimos commits o las últimas respuestas a las issues abiertas para comprobar si un proyecto está vivo o no. Si no hay nadie resolviendo los bugs o actualizándolo a las novedades que van surgiendo, como ecma script 6, es probable, argumenta, que al final te encuentres con graves problemas.

4. El proyecto no está bien documentado ni tiene test, un punto que no necesita mayor aclaración.

5. Aunque el proyecto se anuncia como la solución definitiva para no sé qué, ni siquiera quien lo anuncia lo está utilizando.

Comparto todos sus argumentos y añado algunos que me llevan en mi día a día a decidirme por una cosa u otra.

6. La curva de aprendizaje. La programación frontend está hiper-revolucionada. Cada día surge una cojoherramienta y los programadores vamos con la lengua fuera para no quedarnos deprecated cada semestre. Si para usar algo necesitamos que un equipo entero se ponga a estudiar tres meses, mal vamos. La única excepción son los proyectos que está claro que van a tener un recorrido largo, como pueden ser los web components y polymer, donde se termina por compensar la inversión de tiempo, pero, en general, el que algo sea plug & play para mí es un valor fundamental.

7. Que esté soportado por los grandes navegadores, el Explorer incluido, y sea multidispositivo. Si algo solo funciona en las últimas versiones de chrome y android no me interesa y esto va más allá de los requisitos que pone un cliente: cualquiera que haya vivido los años hegemónicos del Explorer, cuando solo una aldea poblada por irreductibles galos llamada Firefox resistía al invasor, sabe que esos monopolios tecnológicos no son saludables en absoluto.

8. La cercanía con los estándares de la w3c. La normalización de los productos es formidable. Es lo que permite que alguien pueda fabricar una pieza que encaje con otra realizada en la otra parte del planeta. Es la única manera de internacionalizar los procesos productivos y por lo tanto algo interesante para quien es alérgico a las fronteras, geográficas o de cualquier otra naturaleza. De hecho, sin los estándares no podría existir Internet. Además, cuando un proyecto se aleja de los estándares -y más aún si es propietario-, no se enriquece con el trabajo de la comunidad y es más fácil que muera, tal y como ocurrió con flash. Esta es una de las razones, por ejemplo, por las que prefiero polymer a react.

9. Que se lleve bien con el resto del mundo. Nadie puede hacerlo de la mejor manera en todos los frentes, ni siquiera los programadores de google. Siempre habrá tal librería, tal plugin, tal no sé qué mejor en alguna faceta, como ocurre con la familia de angular 1.* y la manipulación del dom, que se hace mucho mejor con jQuery digan lo que digan los talibanes de este framework, que por otro lado es muy bueno. En otras palabras, lo normal es que en un proyecto necesites cuanto menos una decena de cosas, por lo que cuanto mejor se puedan combinar entre sí, menos problemas tendrás. Y, en este sentido, por cierto, es de gran ayuda precisamente que se ajusten a los estándares.

10. Que sea divertida. Aunque pudiera parecer trivial, esta razón es clave, al menos en el mundo frontend. Picar en java es un tostón, solo para hacer un hola mundo miserable necesitas desplegar una batería de cosas en un entorno de trabajo de lo más farragoso, por lo que perfiles como el mío terminan haciendo mal el trabajo de puro aburrimiento. En cambio, si algo me entusiasma, si me divierte, le echaré tiempo y ganas para hacerlo cada vez mejor.

Y dicho esto, chapo por hoy.

 

|| Tags:

valoración de los lectores sobre 10 razones para escoger un proyecto

  • estrellica valoración positiva
  • estrellica valoración positiva
  • estrellica valoración positiva
  • estrellica valoración positiva
  • estrellica valoración positiva
  • 5 sobre 5 (1 votos)

¿Te ha parecido útil o interesante esta entrada?
dormido, valoración 1 nadapensativo, valoración 2 un poco sonrisa, valoración 3 a medias guiño, valoración 4 bastante aplauso, valoración 5 mucho

Tú opinión es muy importante, gracias por compartirla!

Aportar un comentario


*