Los errores de la página 28

Con este curioso título comienza el issue 11446 del repositorio de Symfony. Wouter De Jong, programador holandés que es uno de los máximos responsables de la documentación de Symfony, se queja de la poca atención que se presta a algunos de los issues y bugs reportados en el repositorio de Symfony.

De hecho, Wouter asegura que si miras en la página 28 de los issues de Symfony verás muchos errores y sugerencias reportados hace mucho tiempo y que todavía no han sido arreglados. Wouter va un paso más allá y propone que miremos al pasado antes de continuar mirando al futuro. En otras palabras, Wouter propone que Symfony 2.7 no contenga ni una sola nueva funcionalidad y todo el trabajo se centre en limpiar esos issues.

Por su parte, Fabien Potencier, el líder del proyecto Symfony, responde que es necesario que más personas se involucren revisando los issues y los pull requests que se envían desde la comunidad. A su vez, otros autores responden a Fabien que se debería facilitar más la colaboración de la comunidad.

En el momento de escribir estas líneas, Symfony tiene 821 issues reportados y el más antiguo es de mayo de 2011. RubyOnRails tiene 633 issues reportados y el más antiguo es de junio de 2011. Django tiene 1.313 issues reportados y el más antiguo es de julio de 2005. Y la situación del resto de proyectos grandes de software libre es similar: Ubuntu tiene 111.454 issues pendientes (cientos de ellos críticos), Apache tiene tantos issues pendientes que el listado sólo muestra los 500 primeros, PHP tiene 4.996 issues pendientes, etc.

Y tu, ¿crees que estás cifras son preocupantes? ¿Es normal que tan poca gente colabore con los proyectos que ellos mismos y sus empresas utilizan? ¿Qué ideas se te ocurren para fomentar la participación y así reducir las lsitas de issues pendientes?

Comentarios

  1. Que SensioLabs, en lugar de cobrar 1000 euros para un curso de Symfony2, lo cobre a 300. Esto hará que más gente aprenda Symfony2 y hará subir la calidad técnica de la comunidad, y esto, de rebote, hará que la gente tenga más nivel como para poder contribuir.

    Que en lugar de 250 euros que cuesta la certificación, sea gratis para los contribuidores de Symfony. Una razón más para, almenos, intentarlo. De rebote más gente estudia para sacarse el certificado, y esto, de rebote, hará que la gente tenga más nivel como para poder contribuir.

    Hoy por hoy no hay mucha gente con un buen nivel de Symfony como para poder atreverse con según que issues...

    Es una cuestión de visibilidad... Un proyecto open source tiene alguien por detrás que se lucra de ello (básicos de economía y empresa) y en parte es de ellos la responsabilidad de hacer crecer cuantitativamente y cualitativamente su comunidad.

    Marc Morera el 24 de julio de 2014, 13:57:49

  2. De acuerdo al cien por cien con el comentario de Marc Morera.

    Francisco Aroca el 24 de julio de 2014, 14:20:37

  3. En próximas versiones, Symfony debería comenzar a mover los issues para sus respectivos repositorios y liberar los componentes por separado. A fin de cuenta son componentes independientes no?

    Lo otro que frena mucho la innovación es lo de mantener la compatibilidad. Me gustaría ver otra vez componentes creados desde cero, con total libertad.

    Yosmany Garcia el 24 de julio de 2014, 14:41:36

  4. completamente de acuerdo con marc morera

    marcelo prizmic el 28 de julio de 2014, 1:43:03

  5. Estoy con Marc Morera, entendiendo la necesidad económica de la empresa, si quieres ampliar base y conseguir ayuda, debes ser generoso, con los que ayuden.

    Luciano Caballero el 30 de julio de 2014, 1:55:24

  6. Sobre los datos de número de issues, hay que leer bien la información, por ejemplo en php, son 5 mil pero algunos son de vers 5.2 (que dudo solucionen), otros 5.3, para SO como Windows XP, etc, pero aún así, mejor comparase con los que tienen menos issues que contentarse con ser mejores que los peores.

    Luciano Caballero el 30 de julio de 2014, 2:02:46

  7. Creo que es normal que cualquier proyecto de Software Libre tenga una cantidad considerable de issues, con respecto a lo que comenta Marc Morera totalmente de acuerdo, cursos más baratos harán que exista mas comunidad del framework y por ende aumente la calidad tanto para resolver issues pendientes como para aportar a la comunidad, si ven por acá (México) casi no hay (o mejor dicho no hay) un lugar o empresa decente para tomar capacitación y cuando ves el precio de los cursos (1000 euros) hace que te frenes un poco y que la curva de aprendizaje del framework sea mas lenta.

    Euler Sànchez Gòmez el 31 de julio de 2014, 17:45:34

  8. Espero y deseo que estos posts tengan algún tipo de reflexión por parte de alguien, dados todos los comentarios añadidos.

    Marc Morera el 2 de agosto de 2014, 15:02:12

  9. Pues yo discrepo que con cursos de 1000€ a 300€ vaya a aumentar la comunidad. Y lo mismo con la certificación.

    En realidad, siendo sinceros, y yendo a la certificación, ha tenido bastante menos repercusión de la que yo mismo esperaba y por ejemplo en Londres fuera de Sensio casi nadie sabe ni siquiera que existe.

    Tampoco estoy de acuerdo en que haya que saber mucho Symfony para meterse con muchos de los issues. Y es que simplemente reportando issues correctamente con un fork de la Symfony Standard reproduciendo el bug, comentando en issues, aportando toques a la documentación, etc... se hace muchísimo más de lo que mucha gente cree. Y por toques obviamente no hablo de typos o PHPDoc

    Siguen habiendo muchas partes del framework mal testeadas, buggy o poco documentadas. Y ahí cualquiera puede aportar. Y no digamos ya del frágil ecosistema de Bundles.

    Es preocupante sin duda que haya tantas issues abiertas en todos los proyectos Open Source. En realidad, es preocupante que tan poca gente contribuya a esos proyectos. Y que sigan habiendo MUCHAS empresas reacias a abrir parte del código cuando viven del Open Source.

    Pero es nuestra responsabilidad cambiar eso. Cuántos PR a proyectos abiertos habéis hecho en los últimos 3 meses? Pues eso :)

    Ricard Clau el 18 de agosto de 2014, 16:01:35

  10. Estoy de acuerdo con Ricard. Para mí, las formaciones son solamente a nivel de usuario del framework no de internals. No veo, cómo bajando el precio de las formaciones o de las certificaciones garantiza que la gente entienda más los internals del framework. Son cosas radicalmente distintas.

    IMHO, para arreglar bugs no hay otra manera que arremangarse, ponerle ganas y bajar al detalle. No hay mucho más secreto. :)

    Christian Soronellas el 19 de agosto de 2014, 13:43:41

  11. Estoy de acuerdo en que es responsabilidad de todos que la gente aporte en los proyectos open source, pero ya sabes que en general la sociedad es muy lazy, por lo que las empresas que llevan estos proyectos y se lucran de ellos, deberían promover su popularidad.

    Yo, por ejemplo, me niego a pagar 1000 euros por un curso, primero por que no puedo gastarme este dinero, y luego porque nunca he estado demasiado de acuerdo con este modelo. Lo mismo con la certificación. Y lo curioso del caso es que sé que con ambas, mi nivel aumentaria espectacularmente, y probablemente tendría mucha más eficiencia a la hora de proponer cambios del core de Symfony, eficiencia y eficacia que ahora mismo, sintiéndolo mucho, no tengo.

    Entiendo tu punto de vista, Ricard, pero partes de la base que la gente, por defecto, tiene interés humanitario en gastar su tiempo en proyectos que no tienen repercusión en su economía (y más hoy en día), pero IMO, esta base, no se cumple demasiado.

    Otro punto a tener en cuenta es que hay personajes que critican o evaluan tus PR con mucha mala educación, y es algo muy crítico a la hora de hacer comunidad. A mi es algo que me molesta muchísimo.

    Gran aportación Ricard :)

    Marc Morera el 19 de agosto de 2014, 13:44:51

  12. Amigo Marc, dudo muchísimo que en tu caso haciendo el curso mejoraras tu nivel de Symfony :). No te van a explicar nada más avanzado que una Compiler Pass o un sistema de eventos con el Event Dispatcher... y incluso dudo que esto entren en detalle.

    Y en cuanto a la certificación, como te digo, lamentablemente casi nadie la conoce.

    Entiendo que para tu bolsillo 1000 euros sea mucho dinero pero si lo piensas, para una empresa es bastante poco. Imagina que tienes un equipo de 10 desarrolladores sin ni idea de Symfony.

    Tienes pocas opciones:

    • Contratas los cursos estos a 1000 euros
    • Convences a alguien de la comunidad hispana para que haga lo propio. Si te vas a que esa persona ha de pagar autónomos y le debe gustar comer cada día no te saldrá mucho más barato.
    • Esperas a que aprendan solos y eso te cuesta muchísimo más que los 1000 euros, porque seguramente irán lentos y harán un desastre lleno de bugs.

    Y lo mismo va con el tema de contribuir. Es carísimo reclutar gente buena. Si hay contributors o gente conocida en el equipo es muchísimo más fácil atraer talento. Tanto en Barcelona como en London como supongo en cualquier sitio. Nunca es humanitario al 100%!

    Estoy de acuerdo en que no todo el mundo es igual de majo que por ejemplo WouterJ o Ryan, hay gente bastante seca, pero en mi caso todo lo que me han dicho o tenían razón o me han argumentado claramente su punto de vista. Y piensa que el inglés no es el idioma nativo de mucha gente y eso hace que algunas cosas nos suenen más secas de lo que son

    Vamos, no me han hecho ningún Linus Torvalds aún :)

    Mola el debate

    Ricard Clau el 19 de agosto de 2014, 14:04:41

  13. Olvidándonos de Symfony por un momento, a mí lo que me molesta mucho son esas empresas que llegan a facturar cientos de millones de euros anuales con ayuda del software libre y no colaboran nunca jamás con ningún proyecto.

    Hace poco Dries Buytaert publicó en su blog un artículo en el que demostraba con cifras por qué cualquier empresa con más de 30 programadores Drupal debería contratar a un core developer de Drupal. Lo mismo se podría decir del core de PHP, Apache, Ubuntu/Debian/Linux, etc. que son proyectos críticos para el negocio de esas empresas multimillonarias.

    Javier Eguiluz el 19 de agosto de 2014, 15:00:48

  14. Justamente iba a decir que Marc no creo que aumente mucho su nivel ni con los cursos ni con la certificación. Para mi estos cursos están orientados a nivel principiante/medio. Alguien que va a conferencias y participa en open source ya sea con issues o bundles no se beneficiará mucho.

    Si lo de la certificación no se conoce mucho, entonces es un problema más de marketing que otra cosa.

    En cuanto a los precios, también están apuntados a empresas, no son ni caros ni baratos, pero bajando el precio no creo que tenga influencia en la cantidad de personas que aporten. Los que quieren aportar en general no necesitan estos cursos porque tienen una motivación interna para aprender y aportar.

    Pablo Godel el 19 de agosto de 2014, 15:04:40

  15. Javier, coincido totalmente con esto. Pero creo que no es culpa de las empresas en si, sino de las personas que están a cargo de los departamentos de IT y desarrollo.

    El mundo Open source es un mundo relativamente joven y nuevo. Y la mayoría de la gente no entiende todavía bien como funciona, no se dan cuenta que contratando gente "core" sacaran mayor provecho a la vez que devuelven algo de lo que recibieron.

    Creo que es importante que miembros de la comunidad vayan tomando roles con decisión en estas empresas para ir cambiando esa mentalidad. Tomará tiempo, pero creo que el cambio se dará tarde o temprano.

    Pablo Godel el 19 de agosto de 2014, 15:08:06

  16. A bastante gente con la que he hablado le gustaría colaborar en proyectos OS, pero cuando llegan a cierto tamaño llega un punto que o has estado al corriente desde el principio de las tomas de decisiones tanto a nivel organizacional como de diseño o te cuesta mucho empezar.

    Iniciativas como las HackDays (http://symfony.com/blog/expanding-the-dx-initiative-hack-day-2-aug-23rd) son grandísimas ideas para fomentar la introducción de nuevos colaboradores a proyectos OS.

    Como concepto, me gustaría introducir también la idea de poder registrar tu interés para resolver cierto bug o añadir cierta feature para posteriormente poder pair-program la resolución junto a un core-developer y aprender. Puede parecer un poco contra-intuitivo, pero es como la contratación de junior developers. Al principio perderás más tiempo por tener que enseñar y guiar, pero a la larga los beneficios para el proyecto serán mucho mayores. Y menos trabajo para tí ya que habrá más contributors.

    Alex Salguero el 19 de agosto de 2014, 15:45:09

  17. Alex, tu propuesta es muy buena. Creo que en cierta forma esto se hace durante los hackdays que se dan antes o después de las conferencias de Symfony, donde te podes sentar en la misma mesa con otros core developers (incluyendo el mismo Fabien). Llevarlo a la práctica de forma online sería interesante.

    Pablo Godel el 19 de agosto de 2014, 16:04:15

  18. Si, normalmente se crean mesas específicas para un tema y se desarrolla con un poco de coaching, con la crême de la crême (Ryan, Javier, Luis, etc)

    La verdad es que el año pasado tuvo una pinta genial :)

    Marc Morera el 19 de agosto de 2014, 16:08:05

  19. Si no estoy equivocado, SensioLabs esencialmente obtiene ingresos vendiendo servicios que orbitan en torno a su producto estrella, Symfony. Básicamente, se trata de un modelo de negocio Freemium donde una amplia base de usuarios utiliza su producto pero solo unos pocos pagan por sus servicios, como otros cientos de productos software open source. Ahora bien, ¿de quién es la responsabilidad de aportar soluciones a los problemas de Symfony? ¿de SensioLabs? ¿de la comunidad? ¿de ambos?

    Lo cierto es que suponer que cada miembro de la comunidad (individuo o empresa) va a colaborar aportando un valor proporcional al beneficio que ha obtenido de Symfony es, por desgracia, una utopía. Efectivamente, llevado al extremo más negativo, hay empresas que aun ganando zillones de euros aportan un valor cero al proyecto. Y, llevado al extremo más positivo, hay desarrolladores que, teniendo dificultades para llegar a fin de mes, sacan tiempo para colaborar y aportar gran valor al proyecto. ¿Esto es legal? Sí. ¿Esto es justo? No. Por desgracia lo legal no siempre coincide con lo justo.

    Okay, entonces necesitamos personas que colaboren y dediquen su tiempo y esfuerzo a resolver los issues pendientes. Lo simplifico más y sin sutilezas: necesitamos personas que trabajen. En mi opinión, una persona solo trabaja si... tachán... está MOTIVADA. Sea esta motivación de la índole que sea: económica, responsabilidad, satisfacción personal, reconocimiento, sentimiento de pertenencia a un grupo... Por tanto, el verdadero problema es CÓMO motivar a la comunidad para que colabore en el proyecto y, más específicamente, en esta tarea. No me cabe ninguna duda, viendo las cifras de issues pendientes en Symfony y en otros proyectos, que esta tarea es ardua y difícil. Motivar a una persona para que trabaje sin utilizar incentivos económicos es una tarea titánica. Entonces, ¿qué podemos hacer?

    • ¿Reducir el precio de los trainings y certificación con carácter general? ¿Eso me motivaría a resolver los issues? Quizás me estimularía ha contratar la formación y certificarme pero, personalmente, no me motivaría a colaborar. Podría darle un giro a esta idea: quienes colaboren en esta tarea obtendrán un descuento proporcional en las conferencias, workshops y/o certificación, por ejemplo. De este modo la motivación sería económica, y eso generalmente funciona.

    • Dame reconocimiento/sentimiento de pertenencia a un grupo. Ya están los badges, posts dedicados, camisetas, etc. Quizás algún reconocimiento especial/personalizado a esta tarea pueda motivar a algunos. Pero habría que definirlo de manera concreta.

    • Enfréntame a la realidad. Táctica tipo ONG que busca voluntarios, o Wikipedia cuando pide donaciones. Muestra a la comunidad lo que cuesta desarrollar el proyecto y hazlos sentir responsables, si lo utilizas, te lucras y no contribuyes, no estás siendo justo con el resto... Esto no es muy cool y de partida en un enfoque negativo pero no está de más recordar de vez en cuando que lucrarse con un proyecto al que no se contribuye de ningún modo no es muy ético.

    • Regálame conocimiento. Coincido en que iniciativas como los HackDays son grandísimas ideas. Además estas medidas reducen fricciones, disminuyen barreras, allana el camino de quienes quieren participar.

    Ummm no estaría de más hablar con alguien de marketing y con alguien de HR para buscar ideas acerca de captación, compromiso y motivación. Es un tema muy interesante y bastante complejo.

    Pedro Revueltas el 19 de agosto de 2014, 20:54:43

  20. Personalmente creo que hay muchas formas de colaborar con proyectos OS, y que no se aporta a un proyecto solamente con código o escribiendo documentación.

    Para muchas empresas las horas de un programador son extremadamente valiosas y limitadas. Y digo valiosas no en cuanto a dinero, sino estratégicamente.

    Conozco empresas que siempre tienen posiciones abiertas y siempre están buscando buenos programadores, sencillamente porque con el ritmo de trabajo que llevan no les alcanza con las horas de los programadores que tienen en sus equipos.

    En estos casos, veo muy difícil que estas empresas puedan aportar X horas de sus programadores al mes para que colaboren en proyectos OS. No porque no quieran, sino porque le es prácticamente imposible aportar en de esta forma.

    Por eso creo que también deberían haber otras iniciativas en las que las empresas puedan participar y aportar su granito de arena a la comunidad. Por ejemplo: ayudando a organizar y promocionando eventos, patrocinado proyectos OS, ofreciendo sus instalaciones para la realización de meetups, … y muchas más.

    Como comenta Pablo Godel, es un mundo relativamente joven, donde las empresas y las personas a cargo deben irse educando y poco a poco cambiando su mentalidad.

    Ronny López el 20 de agosto de 2014, 0:28:26

  21. Por defender un poco a la empresa, en muchos casos los responsables ni siquiera saben la tecnología que se utiliza y los programadores no liberan código por miedo a la empresa. Con esto no quiero decir que sea el caso de todas las empresas.

    Otro de los problemas además del lazy developer, es que la gente no es lazy, sino conformista. Eni vida siempre me he encontrado con distintos tipos de programadores. El que siempre quiere más e intenta usar siempre las últimas tecnologías, el que trabaja como si no hubiera un mañana por dinero, y el que hace sus 8 horas siguiendo el guión que le indica su responsable, sea un CEO un CTO o un team leader.

    Esto lo cuento, porque normalmente el que aportará a la comunidad será el primer tipo de programador, pero también hay que tener en cuenta que las empresas se aprovechan de estos programadores exprimiendolos al máximo y eliminando las ganas de seguir una vez fuera del trabajo.

    Ariel Ferrandini el 20 de agosto de 2014, 1:12:34

  22. @Ronny dedicar horas al software libre estaría descartado por las razones que muy bien comentas. Pero ¿no podría la gente dedicar 10 minutos diarios a reportar bugs, proponer mejoras o comentar en los issues de otras personas? Y repito que no estoy hablando de Symfony, sino de cualquier proyecto de software libre que la empresa utilice habitualmente.

    @Ariel, igual también es cosa nuestra hacer algo de pedagogía a esos CTO y explicarles que el software libre no cae del cielo. Sin aportaciones de voluntarios no habría software libre y la empresa se vería obligada a esclavizarse a Microsoft, IBM, Oracle, etc. ¿Por qué no hacer por ejemplo un hackday el último viernes de cada mes para devolver algo de lo que la comunidad te ha dado? Y si la empresa es grande, ¿por qué no contratar a un "core developer" del proyecto X para que trabaje exclusivamente en el proyecto X?

    Javier Eguiluz el 20 de agosto de 2014, 8:54:21

  23. @Javier, totalmente de acuerdo con vos. Necesitamos más activistas fomentando el open source :)

    Pablo Godel el 20 de agosto de 2014, 16:09:07

  24. @Javier: Esa es precisamente la idea, nos toca a todos nosotros fomentar esos hábitos en los equipos técnicos en los que trabajamos.

    Ronny López el 20 de agosto de 2014, 20:48:24

Este artículo ya no permite añadir más comentarios.
¿Por qué? Los artículos cierran sus comentarios automáticamente unos meses después de su publicación para asegurar que estos sigan siendo relevantes.

Publicada el

24 de julio de 2014

Etiquetas

Proyectos Symfony destacados

La forma más sencilla de generar el backend de tus aplicaciones Symfony. Ver más

Síguenos en @symfony_es para acceder a las últimas noticias.