LinuxParty

Leí posts en Slashdot en Barrapunto y en otros sitios: Un artículo publicado en Zorinaq: "I Contribute to the Windows Kernel. We Are Slower Than Other Operating Systems. Here Is Why." -traducido- --(Contribuir con el Kernel de Windows. Somos más lentos que otros sistemas operativos. Esta es la razón)-- publicó un post (luego eliminado) de un anónimo que se identificó y aportó pruebas como programador de Microsoft. En el comentario explica su opinión de por qué el núcleo Windows NT (el que se usa en todos los siguientes, 2000,XP, Vista, 7 y 8). Más allá de las anécdotas, y de que es una visión parcial y subjetiva, es muy interesante lo que desvela. En pocas palabras, la carencia de calidad y eficiencia son más un problema social más que técnico: falta de incentivos, o incentivos equivocados; dar mayor importancia a cumplir los planes establecidos sin desviaciones que aceptar cambios no planificados para mejorar la calidad del producto; la carencia de programadores con experiencia, o el exceso de programadores recién graduados.»

Más detalles sobre cómo la gestión de un proyecto afecta al rendimiento del código en el artículo Por qué el núcleo Windows NT es peor que Linux: problemas sociales y de incentivos.

Esto es lo que se publicó en Slashdot

"En una respuesta que realmente parece ser de un núcleo de desarrolladores de Microsoft, se nos dice acerca de por qué desarrollo del núcleo de Windows sigue cayendo más y más en comparación con el kernel de Linux. Él dice, 'la causa del problema es social. No hay casi ninguna mejora del mismo, en aras de la gloria, que se ve en el mundo Linux. No hay ningún programa formal o informal de mejora sistémica. Empezamos a preocuparnos por la seguridad porque pre-SP3 Windows XP fue una amenaza existencial para el negocio. El bajo rendimiento no es una amenaza existencial para el negocio. los dueños de los componentes son generalmente abiertamente hostil a los parches exteriores: Si eres un desarrollador, aceptando un parche exterior se enfada (debido a la necesidad de mantener este parche y justificar en shiproom el cambio imprevisto de diseño), enoja al tester (porque la prueba está en el gancho para asegurarse de que el cambio no rompe nada, y que acaba de hacer trabajo para ellos), y el PM (Project Manager) está enfadado (debido a las implicaciones del programa de renovación de código). Sin apenas incentivos para aceptar los cambios de fuera de su propio equipo. Siempre se puede encontrar una razón para decir "no", y tiene muy pocos incentivos para decir "sí".