Respuestas:
Fuente abierta
Mira el sitio web del proyecto
Al hacerlo, retoma los siguientes puntos ...
Además, asegúrese de tomar nota de la Licencia bajo la cual se distribuye el software. Algunos pueden no ser adecuados para sus necesidades.
Software empresarial
No tengo mucho que decir aquí aparte de ...
root . Especialmente si va a estar escuchando en un puerto TCP / IP. * Mirando la reputación del vendedorrootacceso, por lo que el producto debe admitir sudo . Cualquier persona que argumenta que sudono es compatible es generalmente solo senil, pero son los proveedores y lo harán). sean los que tienen que apoyarlo; no desea comprar el producto y luego pedirles que le digan "No, no puede usar sudo, debe su para rootear".Falta de actividad. Si el proyecto no ha lanzado un nuevo código, muestra muchos errores no cerrados (o errores que son muy antiguos sin errores nuevos), o tiene foros de usuarios que tienen una proporción muy alta de spam / publicación, eso es un olor seguro a código base en descomposición. Los proyectos activos tienen lanzamientos regulares, errores que indican que los nuevos abiertos no están superando a los antiguos cerrados, y los foros de usuarios con actividad diaria. Los tres son vitales para mantener el código vivo y en buen estado: liberación, retroalimentación y depuración / refactorización, formando un ciclo completo.
La actividad es proporcional al tamaño, la complejidad y la madurez de la base de código. Cuanto más grande es el programa / proyecto, más infrecuentes son los lanzamientos puntuales, pero debe haber un flujo constante de lanzamientos puntuales. Para un proyecto como Samba, con una gran base de código complejo, espere lanzamientos puntuales después de aproximadamente un mes. Para un proyecto como gcc, que es una base de código madura con objetivos de diseño más conservadores, los lanzamientos puntuales son intermedios más largos, pero más grandes. Los objetivos que se mueven rápidamente en cantidades muy pequeñas de código también muestran problemas potenciales: podría ser que los desarrolladores aún estén luchando contra errores o aún no tengan todos los objetivos / características codificados.
El código fuente debe ser fácilmente accesible. En blanco, si es verdadero código abierto, no debería haber ningún apretón de manos mágico, ofrendas de vudú o encantamientos a la luz de las velas para ver el código fuente. No importa si es accesible a través de CVS, SVN, Git, Mercurial o incluso paloma mensajera, siempre que pueda acceder a él sin un acuerdo de licencia de envoltura de clic. Si firma una exención, NDA, o acepta un esquema de licencia desconocido, no está tratando con código abierto, está tratando con un proveedor comercial que ha aceptado abrir su fuente a usted, por un precio .
Hay muchos, de verdad.
Licencias engañosas : hay demasiadas soluciones que intentan matarme. El paquete cuesta X, pero si desea las opciones anunciadas 1, 2 y 3, serán $ 500-1500 más por opción. No gracias.
Nadie lo usa , o al menos, Google no puede encontrar a nadie hablando de eso. Es nuevo (en cuyo caso, eres un conejillo de indias) o tan malo que todo el mundo sabe mejor
Es la raíz de varios tenedores : si algo se ha bifurcado muchas veces, probablemente haya una buena razón para ello, y uno de los tenedores probablemente haya resuelto el problema mejor que la fuente. Investigue esos en su lugar.
Diseño de interfaz consistentemente malo : no me refiero solo a la GUI. Los indicadores u opciones de CLI locos, no identificados o mal etiquetados me vuelven loco
No funciona , o pretende que una situación que debe resolverse no debería existir (o no existe) y, por lo tanto, no la aborda
También agregaría que la tasa de rotación de código es consistente y realizada por muchas personas, no solo algunas. No querrá que una persona genere código a tiempo parcial cuando se entusiasme con su proyecto, luego se aburra y lo deje en manos de la comunidad para que continúe apoyando. Drupal y Joomla son dos buenos ejemplos.
Si está buscando el software para su empresa, venderlo, cambiarlo, etc., el aspecto más importante es la licencia. Mirando la inclusión de busybox en los enrutadores WLAN y siguiendo acciones legales, las compañías piensan que "código abierto = haga lo que quiera".
Algunas otras cosas: también estoy buscando la fecha de la última actualización y una comunidad activa, así que foro, tal vez otras páginas que tengan el software como tema.
En Linux, verificaría qué software incluye su distribución. El software empaquetado no se limita a solo opensource / GPL: Ubuntu, Gentoo y SLES como mínimo incluyen software propietario en sus listas de paquetes. Si bien no hay garantía de que estos paquetes funcionen tan eficazmente como el software central en la distribución, alguien ha invertido tiempo y esfuerzo para preparar un paquete.
Miraría principalmente la madurez y la actividad. Si parece razonablemente maduro y parece haber una buena cantidad de actividad (actividad de foro o wiki, por ejemplo), entonces puedo sentirme bastante cómodo. Entonces sé que hay una buena posibilidad de que se solucionen los errores y que pueda obtener ayuda con los problemas que surjan. Elegiría un proyecto activo que no satisfaga mis necesidades perfectamente, en lugar de un proyecto que parezca una combinación perfecta pero que parezca muerto, cualquier día de la semana.
Cuando se trata de la madurez, depende en gran medida del uso previsto. Si es algo que necesito implementar al instante y que no se puede permitir que falle o cause problemas, la madurez obviamente será un factor bastante importante. Si puedo vivir con algunas peculiaridades y no es crítico con algún tiempo de inactividad, prefiero mirar las perspectivas futuras.