Portada
mis comunidades
otras secciones
#3:
#2
1.- Proporciona informes de lo que te gusta y de lo que no.
2.- Crea peticiones de características que expliquen el uso que tu les das. Describe porque encuentras eso útil y cómo otros se podrían beneficiar.
3.- Prueba el código mientras está siendo desarrollado. No importa cuantos test automatizados se lleven a cabo, la realidad es que el proyecto es una combinación de hardware y software y también otros aspectos del entorno que no han sido testeados por el equipo del proyecto (que de hecho no puede testear todo).
4.- Escribe documentación. La mayoría de los que contribuyen en los proyectos son buenos programadores, pero no escritores (de documentación).
5.- Traduce las interfaces de usuario o la documentación. Mientras muchos usuarios entienden el Inglés bien, también hay muchos usuarios que prefieren una documentación escrita en su lenguaje nativo.
6.- Responde preguntas de los usuarios en foros o listas de correo.
7.- Ayuda diseñando interfaces de usuario, logos, y el sitio web.
8.- Promociona el proyecto hablando sobre él en tu grupo de usuarios locales, escribiendo artículos en un blog, y/o difundiendo las actualizaciones en diferentes redes sociales que utilices.
9.- Proporcionar hardware si existe la necesidad de una compilación dedicada o en servidores de prueba. Puedes proporcionar acceso a hardware directamente a un “datacenter” a los desarrolladores o de manera indirecta ejecutando integración continua o probando tu mismo y ofreciendo los resultados de tus pruebas al proyecto.
10.- Agradecer a la comunidad por su trabajo y sus contribuciones a la causa en la que estas trabajando y las metas que se están alcanzando.
Esto es lo más resumido que creo que puede ofrecerse, más no tendría sentido.
PS: Los tecnicismos deberás buscarlos por ti mismo, sino sería una entrada en un blog.
PS2: He visto ahora un error en las etiquetas, he escrito desarollo y no desarrollo, sorry.
1.- Proporciona informes de lo que te gusta y de lo que no.
2.- Crea peticiones de características que expliquen el uso que tu les das. Describe porque encuentras eso útil y cómo otros se podrían beneficiar.
3.- Prueba el código mientras está siendo desarrollado. No importa cuantos test automatizados se lleven a cabo, la realidad es que el proyecto es una combinación de hardware y software y también otros aspectos del entorno que no han sido testeados por el equipo del proyecto (que de hecho no puede testear todo).
4.- Escribe documentación. La mayoría de los que contribuyen en los proyectos son buenos programadores, pero no escritores (de documentación).
5.- Traduce las interfaces de usuario o la documentación. Mientras muchos usuarios entienden el Inglés bien, también hay muchos usuarios que prefieren una documentación escrita en su lenguaje nativo.
6.- Responde preguntas de los usuarios en foros o listas de correo.
7.- Ayuda diseñando interfaces de usuario, logos, y el sitio web.
8.- Promociona el proyecto hablando sobre él en tu grupo de usuarios locales, escribiendo artículos en un blog, y/o difundiendo las actualizaciones en diferentes redes sociales que utilices.
9.- Proporcionar hardware si existe la necesidad de una compilación dedicada o en servidores de prueba. Puedes proporcionar acceso a hardware directamente a un “datacenter” a los desarrolladores o de manera indirecta ejecutando integración continua o probando tu mismo y ofreciendo los resultados de tus pruebas al proyecto.
10.- Agradecer a la comunidad por su trabajo y sus contribuciones a la causa en la que estas trabajando y las metas que se están alcanzando.
Esto es lo más resumido que creo que puede ofrecerse, más no tendría sentido.
PS: Los tecnicismos deberás buscarlos por ti mismo, sino sería una entrada en un blog.
PS2: He visto ahora un error en las etiquetas, he escrito desarollo y no desarrollo, sorry.
#7:
Cómo NO contribuir en un proyecto de código abierto:
1. Insultando o burlándose de los que prefieren la alternativa propietaria.
2. Pirateando la alternativa propietaria.
3. Comportarse como si fuese un fanático religioso pero en vez de algo divino es una tecnología.
4. Cerrarse a sólo una alternativa de código abierto y despreciando a las demás.
5. Hacer que sus comentarios en foros como menéame sean no para contribuir en el proyecto sino para un propósito egoista: subir karma.
1. Insultando o burlándose de los que prefieren la alternativa propietaria.
2. Pirateando la alternativa propietaria.
3. Comportarse como si fuese un fanático religioso pero en vez de algo divino es una tecnología.
4. Cerrarse a sólo una alternativa de código abierto y despreciando a las demás.
5. Hacer que sus comentarios en foros como menéame sean no para contribuir en el proyecto sino para un propósito egoista: subir karma.
Comentarios
#2
1.- Proporciona informes de lo que te gusta y de lo que no.
2.- Crea peticiones de características que expliquen el uso que tu les das. Describe porque encuentras eso útil y cómo otros se podrían beneficiar.
3.- Prueba el código mientras está siendo desarrollado. No importa cuantos test automatizados se lleven a cabo, la realidad es que el proyecto es una combinación de hardware y software y también otros aspectos del entorno que no han sido testeados por el equipo del proyecto (que de hecho no puede testear todo).
4.- Escribe documentación. La mayoría de los que contribuyen en los proyectos son buenos programadores, pero no escritores (de documentación).
5.- Traduce las interfaces de usuario o la documentación. Mientras muchos usuarios entienden el Inglés bien, también hay muchos usuarios que prefieren una documentación escrita en su lenguaje nativo.
6.- Responde preguntas de los usuarios en foros o listas de correo.
7.- Ayuda diseñando interfaces de usuario, logos, y el sitio web.
8.- Promociona el proyecto hablando sobre él en tu grupo de usuarios locales, escribiendo artículos en un blog, y/o difundiendo las actualizaciones en diferentes redes sociales que utilices.
9.- Proporcionar hardware si existe la necesidad de una compilación dedicada o en servidores de prueba. Puedes proporcionar acceso a hardware directamente a un “datacenter” a los desarrolladores o de manera indirecta ejecutando integración continua o probando tu mismo y ofreciendo los resultados de tus pruebas al proyecto.
10.- Agradecer a la comunidad por su trabajo y sus contribuciones a la causa en la que estas trabajando y las metas que se están alcanzando.
Esto es lo más resumido que creo que puede ofrecerse, más no tendría sentido.
PS: Los tecnicismos deberás buscarlos por ti mismo, sino sería una entrada en un blog.
PS2: He visto ahora un error en las etiquetas, he escrito desarollo y no desarrollo, sorry.
#3 Bueno, con 5 no sé si lo habría entendido todo pero me habrías parecido simpático y listo.
Te explicas mejor que tu propia noticia, te lo digo de mayor.
Cómo NO contribuir en un proyecto de código abierto:
1. Insultando o burlándose de los que prefieren la alternativa propietaria.
2. Pirateando la alternativa propietaria.
3. Comportarse como si fuese un fanático religioso pero en vez de algo divino es una tecnología.
4. Cerrarse a sólo una alternativa de código abierto y despreciando a las demás.
5. Hacer que sus comentarios en foros como menéame sean no para contribuir en el proyecto sino para un propósito egoista: subir karma.
#7 Cómo contribuir a un proyecto de código privativo:
1. Insultando o burlándose de los que prefieren la alternativa libre. Puedes llamarlos frikis o aludir a su condición social llamándoles pobres, está claro que si usan software privativo es porque no se lo pueden permitir.
2. Pirateando la alternativa privativa. Recuerda que tienes que usar todos los productos de software de tu multinacional favorita sea cual sea la forma, pero eso sí, no te olvides de comprar todo su hardware, al fin y al cabo tienen que comer.
3. Comportarse como si fuese un fanático religioso pero en vez de algo divino es una multinacional. No importa el bien común, el beneficio está por encima de todo.
4. Cerrarse a sólo una alternativa de código privativo y despreciando a las demás. Hay que procurar usar siempre aplicaciones y formatos que se salgan de lo estándar para discriminar a los que decidan no usar las aplicaciones privativas y que no puedan trabajar adecuadamente con esos formatos para poder reírnos de ellos por su baja calidad.
5. Hacer que sus comentarios en foros como menéame sean no para contribuir en el proyecto sino para un propósito egoista: subir karma y hacer publicidad, ¿quién sabe? puede que al final acaben contratándote.
#21: A mi más de una vez me han llamado "friki" por preferir el Gimp al Photoshop.
#35: Eso es algo curiosísimo, los que relacionan el SL con el comunismo... pues no, el SL no tiene ideología política, sirve tanto para un comunista como para un libegal. A quién no le gusta en cambio es a los feudalistas, porque molesta mucho eso de usar un programa y no pagar por ello.
#24 A mi ex la llamaron comunista en Coritel por usar el Firefox ...
Falto lo de donaciones monetarias: para pagar gastos operativos como la pagina web del proyecto y cosas asi.
¡Genial encontrarme un artículo en portada invitando a participar en proyectos de código abierto!
Me recuerda a cuando hace ya varios años, en la época de Mozilla Suite, Phoenix, Firebird y años iniciales de Firefox yo tenía una gran participación en el proyecto. Sin ni idea de código ni nada, cada día participaba colaborando "mis ideas", sugerencias, experiencias, probando betas, reportando bugs, etc. No programaba pero sentía que contribuía de otro modo, influyendo en muchas decisiones y aspectos.
Bien es cierto que a día de hoy ya lo tengo abandonado, más que nada porque siento que dicho proyecto maduró lo suficiente como para "no necesitarme". Pero nadie me quita lo bailado y contribuido, que sin ni idea de código me sentía una parte útil de la comunidad que marcó el camino para una Internet libre, de acceso universal.
En fin, ojalá sigan apasionándose las nuevas generaciones en hacer y contribuir juntos.
Relacionadas:
Como contribuir con los proyectos de código abierto si no eres programador (eng)
Como contribuir con los proyectos de código abiert...
opensource.comComo se puede contribuir a los proyectos abiertos y libres sin necesidad de ser programador
Como se puede contribuir a los proyectos abiertos ...
libuntu.comEsta noticia es más extensa que las relacionadas y en el caso de la primera relacionada, esta está traducida.
#1 Te reto a resumirme la noticia como si tuviera 5 años
#2 Niño se bueeeno. No seas maaalo. Mira que si te portas mal no te compro un escalestris.
#9 He sido buena, señor Roqueford España. Prefiero un castillo.
Si eres una tía buena, prometiendo sexo a los programadores que más hagan progresar el proyecto.
Necesitamos diseñadores para KDE. Se ve bonito pero el tema de iconos por defecto es inconsistente.
#6 Alguien tendrá que poner-se las pilas en lo de los iconos Oxygen porque está medio abandonado. Si alguien puede y quiere ayudar supongo que la mejor manera es contactar con Nuno Pinheiro, que según la Wikipedia es el responsable de Oxygen.
Pero tened en cuenta que ahora mismo los diseñadores de KDE están bastante ocupados trabajando en mejorar la interfaz de usuario y la consistencia entre aplicaciones; y en ir puliendo la nueva versión de Plasma Desktop.
Hola,
Escribo desde mi punto de vista como desarrollador de Software Libre.
Desde el 2006 llevo liberando software libre, muchas cosas pequeñas utilidades y desde el 2009 con http://open-classifieds.com/ y desde hace nada http://open-eshop.com/.
Personalmente apreció muchisimo a la gente que desinteresadamente nos han ayudado y desde aquí quiero dar las gracias.
Para poneros en perspectiva el software se ha descargado más de 270.000 veces y hay unas 15.000 webs activas.
Como cosas buenas:
Algunas buenas ayudas en el foro y comunidad decente
Muchas sugerencias muy buenas
Traducciones
Colaboraciones espontaneas en el desarrollo (unas 5 personas que habrán picado un 5% del código)
He aprendido muchisimo, ni me lo imaginaba.
Hemos conseguido un modelo de negocio basado en el soporte y temas que al menos me permite llegar a final de mes (cobro 1000€ al mes).
Me ha abierto muchas puertas en otros trabajos.
He mejorado mi Inglés y me ha permitido viajar
He conocido excelentes personas.
Me permite trabajar desde casa bastante.
Cosas malas:
Falta de inversión pese al interés
Muchas criticas por que no cumple con la funcionalidad que alguien quiere y no quieren ayudar.
Publicados bugs con malintenciones sin comunicarnoslo previamente (una vez pegué una cagada del carajo podías borrar la BBDD entera )
Copias de otros sin respetar la licencia GPL v3
Las donaciones han sido mínimas creo que desde 2009 se an recudado unos 800€.
Recibido amenazas porq ue no contestabamos en el foro gratuito tanto como la gente deseaba.
He invertido en total más de 15.000€ en mi tiempo empleados diseño sub contratas etc..ahora empieza a devolverse.
Como nos puedes ayudar
Ideas, donaciones, mejoras de el contenido, guías de ayuda y cualquer cosa que se os ocurra!
Perdonad el tocho pero me venía a huevo
#14 Desgraciadamente, lo que describes es bastante común también en las empresas privadas de desarrollo de SW.
#16 Pero en una empresa privada de desarrollo, estás "obligado" a aguantar a tu cliente, por muy pesado que sea, porque es el que te está pagando. Y si tienes que buscar formas creativas de decir que el problema está entre la silla y el teclado, pues lo haces.
Pero si estamos hablando de un desarrollo colaborativo, abierto y donde no me están pagando por resolver los problemas de la gente, no pueden pretender que se les dedique una sonrisa cada vez que repites "¿has probado a seguir el paso tres de la guía, como indican las preguntas frecuentes en relación a tu problema?". Esa es la diferencia. Puedes llamar a vodafónica para decirles que "Google no me va", pero no puedes poner un bug diciendo "Google no me va" porque no voy a mandarte a un técnico a tu casa a mirar qué pasa.
#16 #18 teneis razon, yo ando de moderador de trackers tanto de software abierto como cerrado, y si al de software cerrado hay que tratarlo con palmitas y hacerle ver su error sin que eso implique que el tio deje de ser cliente (sobre todo cuando es una gran compañia) pero a veces dan ganas de llamarles idiotas y toca decir a los programadores de hacer cambios para hacer el software mas a prueba de idiotas que te hacen preguntarte como son capaces de usar un ordenador.
http://www.trinitycore.org/f/topic/1518-trouble-with-your-trinity-install-readme-1st-faqs/ un ejemplo
http://www.trinitycore.org/f/topic/328-solved-unknown-column-error-trashbin/
Esto se puede aplicar esto a más ámbitos de la vida y no solo al software. Da igual el ámbito en el que seas especialista,s iempre hay algo que construir y del cual liberar sus especificaciones, patentes, instrucciones...
A los quien le guste el diseño industrial, por ejemplo, pueden construir fabulosos modelos libres o ampliar proyectos existentes.
Existen infinidad de máquinas y recursos que trabajan sobre bases opensource bien especificadas. Por ejemplo el proyecto RepRap, ShapeOKO. Que trabajan sobre hardware de guiado lineal como makerSlide (http://www.makerslide.com/) o openrail (http://openbuildspartstore.com/openrail-black-anodized/)
Recordad, en sitios como github o sourceforge, no solo se pueden usar para liberar código fuente, también se puede subir cualquier tipo de archivo, desde un sketchup a openscad.
Este también es un repositorio libre que la empresa makerboot ha puesto a disposición de la comunidad. Se llama http://www.thingiverse.com/
La comunidad maker también es open source, no nos olvidemos de ella
Sí, puedes colaborar en un proyecto de código abierto sin escribir código.
Pero si lo haces, vete preparado a ser tratado como un miembro "inferior" por una parte de los programadores.
Algunos se creen, poco menos, semidioses (o tiranos) y todo el que no sepa leer código es un ser despreciable e indigno.
Siempre se caracteriza a estos proyectos como "meritocracia". Yo los caracterizo más como "puñetera jungla": caóticos y solo sobreviven los más persistentes.
Por suerte no todos los proyectos son iguales. Pero hay demasiado ego en el mundo del software libre.
Muchas veces también lo puedes hacer con muchos productos de código propietario.
Bien, ahora ya puedo contribuír al programa.
Lo mejor es opinar sin abrir la noticia. Porque ya nos la han contado en la entrada. Lo de illa sobra. Y aquí hay que espabilar, que hay mucho por hacer.
A mi me parece que en definitiva todo se resume en que hay que involucrarse en el. Sin embargo el título me llevó a pensar que trataba de lo contrario, como contribuir a un proyecto esporádicamente si no vas a involucrarte a fondo.
También hay que tener en cuenta que muchas veces se aprecian más soluciones que "problemas". Muchos desarrolladores se toman el que reporten un bug como una queja, hasta el punto de ser defensivos: Sí, hay un fallo, pero es tu problema, no lo uses o úsalo de otra forma.
#11 Siempre es mejor tener un reporte de bug sin cerrar a no tener reporte de bug.
No sé qué mala experiencia tendrás reportando que piensas que los desarrolladores se lo habrán tomado a mal, pero seguramente esté más relacionado con la forma en la que se reporta el bug, que con el hecho de reportarlo en sí. Lo digo porque (no sé tú caso), me he encontrado bugs bastante arrogantes que parecen tratar a los desarrolladores más como esclavos que como contribuyentes.
#13 Exacto, muchas veces la gente que reporta bugs no sigue las normas de como reportarlos, pasa de buscar antes de publicarlos o reporta bugs de revisiones muy antiguas sin preocuparse de actualizar y probar si existe en la ultima version. O lo que tu dices de los que piensan que los programadores son sus putas o que su bug es critico cuando en realidad es una cosa muy menor. Tambien estan los que reportan bugs que no son bugs o los que abren un hilo en el foro del programa sin antes preocuparse de leer las ayudas existentes donde muchas veces sus dudas estan solucionadas.
#13 Por supuesto que hay de todo, y precisamente por eso también menciono el caso contrario, porque en este meneo se pretende conseguir que la gente se involucre. Si alguien que pasa por allí, de por sí ve que no hay ganas, se va.
A cuento de lo que dice #14, también date cuenta que muchas veces se exige demasiado a alguien que simplemente pasa por allí por primera vez. A lo mejor me dices que buscar en muy sencillo, y lo es, el problema es que buscar bien es mucho más complicado y es todavía más complicado saber si tu problema de que por ejemplo no funcione un botón es el mismo que se reportó hace dos meses, o es una aparición nueva o es el mismo bug con otra causa, o si tienes que irte a la versión no estable para saber si ya está corregido. (y ahí ya empiezas a diluir la línea entre alguien que reporta un bug y un programador que busca el fallo de un algoritmo)
Desde luego la educación es inexcusable, pero ahí también haría falta algo de mano izquierda para tratar ese tipo de gente. Mi experiencia es la que ya he comentado, reportar un bug y que no se cuestione si el bug existe, si es un problema particular mio, nisiqueira si está bien reportado sino que directamente cuestionen qué para qué quieres que se solucione. Y ya ni hablar de cuando reportas algún fallo de usabilidad y resulta que es un bug zombie que siempre reportan cada año pero que sigue por ahí muerto.
Sinceramente creo que la mejor colaboración que puedes dar es participar en el proyecto solucionando problemas, toda la demás ayuda ya vendrá cuando se cumpla con esa parte y proyecto avance.