ChichaPlanet

Emprender, una palabra bastante popular en los últimos años; generalmente asociada al sector productivo e industria, en nuestro país poco se ha tratado sobre éste en relación al emprendimiento en tecnología. El jueves 16 tuve la oportunidad de ofrecer un charla en el marco de la III Semana de ciencia de la computación 2008 en la Universidad Nacional de Trujillo, evento organizado íntegramente por estudiantes de la carrera de computación.

En mi charla, que duró un poco más de lo que pensé, me propuse a hablar algo en lo que estoy particularmente interesado hace algunos años: el emprendimiento en tecnología desde Perú. Este es un resumen de lo tratado en espera de comentarios e interacción con los interesados en el tema, y que sea de utilidad a quienes están evaluando seguir este camino.

¿Para qué estudiamos?

Es posible que en algún momento, previo o posterior, a nuestra actividad académica nos hayamos hecho esa pregunta. Porqué decidimos pasar 5 años, en promedio, de nuestra vida entre libros, café, insomnio y algo de stress. ¿Cuál es el objetivo de todo esto? Para algunos será tener una profesión; para otros, adquirir una posición ventajosa en el mercado laboral, obtener reconocimiento social, obtener un grado académico, etc.

¿Porqué trabajamos?

Son pocas la veces que nos ponemos a analizar el porqué decidimos destinar 8 horas diarias, 40 semanales, a una actividad que nos saca de nuestra camas muy temprano, se convierte muchas veces en el centro de nuestras actividades y puede ser el principal móvil de nuestras satisfacciones o frustraciones.

Respuestas hay muchas, generalmente todas difusas del punto principal. Para no revisar todas vamos a simplificarlo: trabajamos porque necesitamos el dinero. Validamos esta afirmación con el dato de que de tenerlo, muchas personas no trabajarían.

Esto deriva en otra pregunta: ¿trabajamos en lo que nos gusta?. En mis diapositivas muestro un aviso tipo de oferta laboral para estudiantes de computación (los errores ortográficos y gramaticales vienen gratis).

Profesional, con el siguiente perfil:
- Mínimo dos años de experiencia en el Desarrollo de Aplicaciones
- Conocimientos intermedios/avanzados de Power Builder
- Deseable, conocimientos de Sistemas Contables y Financieros
- Deseable, conocimientos de UML, RUP, PMI
La modalidad de trabajo inicial es para un proyecto de mediano plazo, bajo la modalidad de recibos por honorarios, con grandes posiblidades de permanecer en la empresa en forma permanente.

¿Qué nos apasiona?

Esto es un tema mucho más personal que los anteriores, en mi caso son 3 cosas, que derivan en otro tanto más: las mujeres guapas, sobretodo una en particular; la computación y la música.

Emprendimiento y academia

En nuestro medio, salvo iniciativas aisladas y todavía por madurar, este tema esta más ligado a la búsqueda de personal a poco costo a quien derivarle tareas complicadas que al mútuo aprovechamiento de las capacidades y fortalezas.

En mi opinión la academia debería ofrecer una formación para:

• Conocer cómo hacer tecnología,
• Estar habilitados en conceptos base de computación,
• Incorporar nuevas tendencias solo como complemento mas no como razón de ser,
• Dar capacidades para desarrollar habilidad de identificación de problemas por resolver,
• Conectarse al entorno académico global.

Emprender a través de proyectos de software libre

El participar de proyectos de software libre ofrece al estudiante de computación la posibilidad de aplicar sus conocimientos teóricos en problemas y casos reales, trabajar en problemas complejos e interesantes, interactuar con estudiantes y expertos en la industria, y, además, generar una reputación a través del trabajo realizado.

¿Cómo, donde, y cuando emprender?

Cada uno de los aspectos tiene una o muchas respuestas, sin embargo, la idea de la charla ha sido ofrecer un panorama sobre las posibilidades, retos y algunos consejos para quienes deciden lanzarse en este estilo de vida.

En nuestro país, al igual que en muchas actividades, el emprender es una decisión que implica muchos, muchos retos y situaciones difíciles. Si deseas emprender debes tener esto en cuenta en primer término.

Voy a comentar un poco sobre algunos de estos:

• Financiamiento, este es uno de los principales retos con los que se enfrenta el emprendedor local. No existe un mercado de capital de riesgo para emprendimientos en tecnología, como en otros paises, sin ir muy lejos Chile o Argentina. Existe sí capital de riesgo para emprendimientos de productos tangibles, generalmente exportación. En COFIDE también hay un fondo similar, que podría incluir productos intangibles (software) de ser lo suficientemente atractivos.
• No existe mercado desarrollado para productos de base tecnológica, es decir para componentes de software o hardware que forman parte de un producto final. En nuestro país todavía no vemos casos de empresas que desarrollen tecnología para otra empresa de tecnología. La mayor parte de empresas trabajan en aplicación de tecnología y ofrecen soluciones sobre estas. Por supuesto, al no existir demanda, no hay iniciativas de oferta.
• Mercado aún pequeño para productos de tecnología, esto es bastante claro, la tecnología todavía no es algo muy difundido en todo nuestro país, y algo que debemos tener en cuenta.
• Ausencia de modelos, nuevamente el tema de modelos; que es claro: no existen modelos de empresas o empresarios que hayan logrado desarrollar productos de tecnología exitosos a quienes los jóvenes puedan mirar, seguir y superar.

Sin embargo, también tenemos grandes oportunidades que nos da la nueva situación en la que nuestro país se encuentra.

El crecimiento económico de los últimos años ha ampliado la base de capacidad adquisitiva y nuevas empresas, ha desarrollado clusters de producción especializados, tecnología aplicada a la producción, entre otros. Aquí se presenta un nuevo escenario en donde la tecnología tiene un espacio en el que aportar al desarrollo del país. Lo acaba de decir el ex-ministro Carranza en la entrevista de El Comercio:

Muchas veces se percibe que el sector empresarial se acerca al Estado o para hacer un lobby o para influir en un asunto particular. Eso tiene que cambiar. Si tengo las mejores prácticas en compras, en sistemas de información, en ética puedo ayudar

La crisis mundial, llegue con fuerza o no, también representa una oportunidad para innovar, para ser creativos, para ofrecer productos de calidad que hagan igual o más con menos. Está claro para todos que en este momento las soluciones y productos de software libre van a tener gran demanda por sus características en cuanto a TCO.

Por otro lado, el mercado local todavía no explora algunos modelos de negocios en tecnología. Entre estos los modelos para la base de la piramide, el esquema “long-tail”, y los modelos “freemium” y la “gift economy”.

Por supuesto, nuestro enfoque no solo debe estar en el mercado local, sino también, mirar a un mercado global, cada vez más conectado y más inter-relacionado.

Finalmente ofrecí algunos consejos para quienes deseen emprender.

• Perder el miedo, saltar al vacío, dejar de pensar y hacer, ¡mandarse!. Esto es como cuando te gusta una chica o chico.
• Enfocarse en solucionar un problema específico y hacerlo de una manera creativa e innovadora que te diferncie de lo que hay. En computación resolvemos problemas, hagamos eso y bien.
• Enfocarse en lo importante (tecnología), no intentar jugar al administrador, contador, marketero, etc. Existen otras personas capacitadas en eso que estarán contentos con ayudarlos en esas tareas. Nuestra fortaleza es saber desarrollar tecnología, no lo otro.
• Ahorrar costos, que implica utilizar infraestructura disponible gratuitamente, servicios como Google Apps, y otros nos ofrecen la capacidad de montar toda nuestra infraestructura en la nube y no tener que incurrir en gastos innecesarios, sobretodo si, como cualquier startup, no disponemos de gran inversión. Ahorrar lo máximo posible es clave para el desarrollo de una nueva empresa. En cuanto a equipos y software GNU/Linux y Mac representan una alternativa bastante sólida en cuanto a cost-beneficio, que nos evita problemas al final del día, si Usted utiliza Windows sabrá a qué me refiero.
• Incorporar entusiastas en nuestro proyecto. Existen personas muy generosas que estarán felices de ayudarlo en el desarrollo de su idea de negocio, atraígalas y hágales partícipe de su emprendimiento.
• Difundir, difundir, difundir, en donde vaya, en donde sea, en cualquier momento del día, y noche, ¡cuente su idea a todo el mundo!. Si Usted la cuenta, no la pierde, contrariamente a lo que se suele pensar en nuestro medio, ¡ahora tiene alguien más trabajando en ella!

Creo que la charla ha sido bastante motivadora para los estudiantes participantes del SECICOMP, espero tener novedades de ellos ya que la feria de proyectos me dio muchos motivos para pensar que será así. Agradezco nuevamente a los organizadores del evento a través de Nils, Eduard, Jorge, Pedro, las chicas y todos los amigos de la UNT con quienes pasé un gran día.

Espero que esto sirva también para iniciar un diálogo sobre el tema aquí. Voy a ir publicando cosas que tengo en cartera sobre este tema cada vez que pueda.

Las diapositivas de la charla se pueden descargar aquí:

Emprendimiento y academia

El pasado 24 de junio a invitación del Chapter Lima del PMI ofrecí una charla respecto a los aspectos o practicas de gestión de proyectos que las organizaciones o empresas pueden rescatar del ecosistema de software libre e incorporarlos en sus proyectos, en específico los que tienen que ver con desarrollo de software.

La objetivo principal, más allá de dar a conocer el software libre como tal, era establecer y reconocer prácticas de gestión y procesos que se puedan rescatar e incorporarlos en el desarrollo de proyectos de software de las organizaciones.

La charla inicio ofreciendo un panorama general de los actores que participan en el desarrollo de proyectos de software libre, como podemos ver en el gráfico adjunto, a saber:

• Proyectos en sí,
• Usuarios finales: que incluye a personas, empresas, sector público, organizaciones sin ánimo de lucro,
• Asociados de los proyectos, que son las organizaciones que apoyan a dichos proyectos, caso gobiernos o empresas,
• Partners de los proyectos, que pueden ser empresas u otros proyectos que ofrecen infraestructura base a los mismos,
• Comercializadores de los proyectos, que son las empresas que se dedican a dar un soporte y canal comercial a los productos desarrollados bajo este modelo de licenciamiento.

Luego de esto explique el esquema de trabajo y gestión de los proyectos de software libre, la forma de organización, su estructura jerarquica, infraestructura de trabajo, interacción entre el grupo humano, etc.

A partir de esta información rescatamos algunos valores o prácticas que las organizaciones que realizan desarrollo de software pueden incorporar para mejorar su gestión y procesos de desarrollo.

Entre estos podemos mencionar a los siguientes:

Confía en tu equipo

Esto se refiere básicamente a que la información acerca del desarrollo, incidencias y progreso del proyecto se maneje de manera abierta, sin ocultar información a nigún integrante del equipo. Todos deben estar claros de lo que ocurre. Un esquema bastante similar al definido por Debian y lo que conocemos como el rol de «dictador benevolente».

Revisa todo, prueba todo

Que trata de resumir la necesidad de incorporar y establecer prácticas de testing en el proceso de desarrollo y aprovechar las herramientas de software, o construir las necesarias, para establecer un ciclo constante de auditoria general y automatización del proceso de pruebas de software. De esta manera a medida que se va desarrollando el proyecto también se tiene a la par un proceso que puede garantizar la validación de su funcionalidad.

Todos los desarrolladores son iguales

Algo que no se refiere a las características personales o de formación, sino a la equidad y valoración de las ideas o aportes de los desarrolladores, sean los más experimentados en el equipo o novatos que se acaban de incorporar. Cualquiera de ellos debe ser escuchandos y sus aportes o ideas respecto al desarrollo o diseño de los proyectos se debe tener en cuenta de la misma manera.

Y finalmente, la premisa que no debemos olvidar:

La mejor manera de finalizar un proyecto de forma exitosa es hacerlo de la forma correcta

Que básicamente nos recuerda que aunque tengamos los procesos definidos, las herramientas necesarias y la infraestructura de soporte para el desarrollo de nuestros proyectos; si los primeros se ignoran y no se siguen desde el inicio del proyecto, por razones de tiempo, urgencia, etc; es mucho más probable que a medida que se desarrolle el proyecto ocurran problemas que si se empieza de la forma correcta.

Esto es lo que cuenta al final del día y puede ser el factor crítico que conduce a pérdidas de tiempo, dinero y time-to-market para una organización. Para que un proyecto sea exitoso se requiere la participación de todos los actores involucrados, que va desde la gerencia hasta el desarrollador. No se trata simplemente de dar indicaciones al programador y encerrarlo un número de días esperando que entregue un resultado maravilloso.

Fue interesante el aprovechar que me antecedio una charla sobre  SCRUM, para vincular muchas de estas practicas que tambien son promovidas por frameworks de desarrollo ágil como éste, que fue expuesto por Tobias Mayer de AgileThinking.net.

Es posible que existan otras prácticas que los proyectos de desarrollo de software en las empresas puedan incorporar, si has identificado o aplicado alguno ¡dejanos saber!.

Existe más información sobre el tema que he tomado como referencia para esta charla. A continuación pongo algunos enlaces de referencia:

• Sitio web del MIT que reune trabajos de post-grado sobre temas de software libre. http://opensource.mit.edu
• Articulo sobre el tema en OnLamp de O’reilly. http://www.onlamp.com/pub/a/onlamp/2006/02/27/what-corp-projects-learn-from-open-source.html
• Consultora Stellman Greene: http://www.stellman-greene.com
• Consultora Construx: http://www.construx.com

Yesterday I attended the Ubuntu 8.04 Hardy Heron LTS Release Party event the folks from Ubuntu Peru and Linurp organized here in Lima at Universidad Ricardo Palma. Nice talks on Ubuntu, KDE, GNOME, Drupal and PHP among some other stuff. I particularly liked the talk by the good old Jesus Castagnetto of PEAR and Professional PHP Programming fame. His slides (spanish) are posted at his site. My summary including bits i’ve been adding follows:

• PHP is an easy language to pick up & learn but it’s a bit tricky to master
• During the development phase of your project set the error_reporting value of php.ini to E_STRICT in order to get all sort of errors
• Please set an error log and read it! You are going to need it to monitor your application when it’s deployed for production. Don’t forget to stop displaying errors to the end user in production sites. If you do, chances are you’re disclosing very useful information for an attacker trying to take control of your site or shutting it down.
• If you’re using clean urls (and you should!) and not using the .php extension for your pages you don’t need to disclose that you’re site is running PHP. Setting the expose_php value to zero in php.ini might be a good idea.
• Please get rid of code (yours or written by someone else) that depends on registers_globals = On. This configuration option won’t even exists when PHP 6 is released. Having PHP or your own code create global variables automagically from data sent by the user is a major security threat. So please resit the temptation of using it.
• Please stop using magic quotes. Today they’re not a good idea. Actually they never were a good idea and will be depracated in PHP 6. As the programmer you’re responsible for adding quotes properly to any string that might need them.
• Since version 5, PHP got exception handling. Please don’t abuse then exception handling mechanism by raising an exception at the minimal user-generated error. Raise an exception instead when a critical condition that is need for your program to continue working properly is not met, specially when you expect some other part of you code catching the exception and doing something about it.
• Exceptions can consume considerable memory if your stack trace gets big. They are useful but not cheap.
• Don’t debug you’re code using exclusively echoes, prints and var_dumps. You should be using a proper debugger instead. A very good one is XDebug. You get the extra advantages of getting a full stack trace and profiling capabilities.
• No matter if you’re a solo coder or part of a team you need to follow coding standard in order to produce a consistent-looking codebase that can be easily read by anyone including yourself. PEAR has a good coding standard that has been proved in many PEAR contributions over a good few years. The Zend Framework provides you with a newer coding stardard (draft) that is also based on PEAR’s.
• Documenting might be a bit boring but it’s critical for the success of your project over it’s lifetime. If you’re code is non-trivial you’re much better embedding good documentation in it that will help you in the first place to understand that are those lines of code doing when you come back to make changes. A quality tool for generating PHP documentation is phpDocumentor. It’s fast and can generate not just only API docs but tutorials by parsing your code if you learn to use it properly.
• Please don’t reinvent the wheel. PHP has lots of useful functions that are implemented in C and will definitely run faster than you’re code. If you caught yourself reimplementing native functionality it’s your fault for not reading the manual and keep up with the changes and additions to PHP and it’s core extensions. Know your tool. Investing a bit of time in reading the manual will definitively pay off.

There are a few tips related to OOP with PHP, specially PHP 5:

• Don’t over-engineer your code. PHP is not Java and in many circumstances you’ll be good using just a simple array which is a native data structure instead of a user defined class. Keep things simple.
• Don’t use is_a() but instanceof() instead for checking if an object is a member of a class since is_a() was depracated as of PHP 5.

In order to improve the security of your code you can follow this guidelines:

• You must ALWAYS initialize your variables, specially those involved in authentication, authorization and security checks.
• Never ever trust your user on providing the right kind of input for your program to work properly. You must always validate that the user’s input is good for you
• PHP has the filter and ctype extensions for validating user input. You can always use regular expressions for custom validations.

Finally, for performance improvements you have this recommendations available:

• Don’t use double quotes in strings if there’s no variable interpolation or character escaping taking place. This saves a few miliseconds in each string so if you have many strings in your code and many visits in your website this alone can be a huge CPU and time saver.
• In many places you can speed things a bit up by avoiding string concatenation. Just use a comma in echo to get the same output effect.
• Prefix variable incrementation is a bit faster than postfix incrementation so if you’re not assigning the value of the variable before incrementing it you can easily gain a few extra milliseconds and consume less server CPU with this simple change so you ++$i instead of $i++ whenever you have the chance.
• By all means you must avoid recreating the same dynamic content over and over again if you can be sure it won’t be changing. This is when content caching comes handy. Something as simple as reading a generated HTML chunk from a file in the filesystem instead of issuing again the database queries and/or performing the calculations needed to generate can be a big improvement. Generally cached content is not useful or trusty after some period of time has passed so put your attention in regenerating the cached content when it’s no longer valid.
• Your own PHP can benefit a lot from using a caching mechanism so PHP doesn’t have to compile your code over and over again if it hasn’t change. Avoid wasting server CPU and response time. APC is a very good code caching solution for PHP and is mantained by Rasmus Lerdorf, the creator of PHP himself.
• Don’t guess which parts of your code are the bottlenecks. Use a profiling tool instead. Remember XDebug includes a profiler.
• Even if it’s not something you do at the PHP level you can always take advantage of a data compressing mechanism like Apache’s mod_gzip. Compressing content in both requests and replies is something that has been available in the HTTP specs for a while and you can easily save up to 80% of the bandwidth and response time.

I really think it’s a good idea to use lists like this as check-lists and use the techniques in your projects.

Keep this link with you and help spread the word:

El pasado 14 de marzo ofreci una charla en el Linux Week 2008 organizado por Linux-IDES de la PUCP. por invitación de Genghis. La temática estaba abierta asi que tuve un momento de incertidumbre acerca de qué hablar. Mis opciones estaban entre algo super técnico, tipo sistemas operativos, o algo relacionado con la empresa, por la naturaleza del evento académico.

Finalmente, y gracias a una sugerencia, decidi hablar sobre algunos temas relacionados a las cosas en las que estoy involucrado en estos últimos meses. Así que me propuse hablar del estado del arte del software libre en la empresa. Sin embargo, durante el proceso de trabajar mi charla, que también tuvo su propia historia, me animé por abrir un poco el panorama y hablar de innovación y las tendencias actuales en el sector de empresas de tecnología.

Ya había tocado el tema en la conferencia Día Debian en la UNI, así que esta vez tenía que escalar un poco más y ofrecer algo más interesante que sirva a los asistentes. Me propuse, entonces, ensayar el famoso método Lessig para las presentaciones de apoyo y con el fin de controlar mis tiempos.

En mis últimas charlas he ido dejando de utilizar presentaciones en forma progresiva, incluso la de la UNI la hice bajo el precepto de que: si voy a mostrar cosas de la red, las muestro directamente y no hago ninguna presentación. Mi presentación es la propia actividad que hay en la red. Aquella vez, solo fui con una lista de los enlaces que mostré.

Para esta charla quize apoyar mi «speech» con material visual que ayude a reforzar la idea que estoy transmitiendo. Estoy convencido de que el utilizar las presentaciones de una manera distinta, como por ejemplo para leer el «speech» u otros, es una falta de respeto al público (que también sabe leer).

Ya que iba a utilizar el método Lessig tendría que esforzarme más, primero para tener un mejor orden en la transmisión de las ideas y segundo para controlar los tiempos y tratar de estar sincronizado con la presentación de fondo. Asi que estuve ensayando dos días para tener eso bajo control, creo que el resultado ha sido bastante bueno para esto que llamo «experimento». Me gusta experimentar el hacer las cosas de mejor manera cuando se puede, y he quedado contento (no conforme) con el resultado.

Volviendo al tema de la charla, me ha gustado lo que preparé. Empece con una reseña del inicio del software libre (rms, Linus, Ian), el modelo de negocio que existía en ese momento, las primeras empresas que se formaron. Luego, explique el tema de innovación disruptiva, para posteriormente hacer la relación con el modelo de desarrollo y negocios que se ha formado en torno al software libre.

Posteriormente revisamos el uso de este tipo de esquemas de desarrollo en entornos empresariales, donde cada vez son más importantes los conceptos de e-R&D, innovación, desarrollo de comunidades, el cambio del rol del consumidor a pro-sumidor. Tome como ejemplo a los startups 2.0 y explique cómo estos emplean estos modelos y conceptos que han hecho que sean mucho más exitosos que sitios similares pero con el enfoque tradicional (digg vs. slashdot, myspace vs. mtv.com, etc).

Revisamos la relación empresa-academia, algo que particularmente me interesa, y fue uno de los motivos por los que esta charla en la PUCP fué de particular importancia para mi. También trate el tema del Microsoft de hoy, que parece muy animado a promover el software libre, junto a otras empresas tradicionales. Finalmente hubo una interesante rueda de preguntas donde conversamos sobre innovación, oportunidades para estudiantes, modelos de negocio, realidad virtual, teletrabajo y los beneficios del publicar código.

He quedado muy contento con esta charla, ya puedes notarlo, y espero que se vuelva a repetir en algún momento y sirva para acercarnos más entre academia y empresa. Nuevamente agradezco la oportunidad a Genghis y el grupo Linux IDES.

Hoy me enteré que ya se ha publicado el vídeo de mi presentación, asi que aquí lo pongo. Las diapositivas no son «usables», ya que han tenido otro enfoque y son cerca de 200 (una cada 5 segundos, y de acuerdo al cáculo termine en media hora).

Si te interesa el material o los datos de referencia de temas que trate dejame un mensaje y actualizaré este post o te escribiré directamente.

Charla en la PUCP, Linux Week 2008

ShareThis

Mon 18th Feb - Fri 22nd Feb @ #ubuntu-classroom on Freenode!

Digg It!

Welcome everybody! I’m very very pleased to announce the first ever Ubuntu Developer Week . What this means? We’ll have one week full of action-packed IRC sessions where you can:

• learn about different packaging techniques
• find out more about different development teams
• check out the efforts of the world-wide Development Community
• participate in open Q&A sessions with Ubuntu developers
• and much much more…

I’m absolutely excited to have such a diverse programme and thrilled we have so many excellent speakers in the first ever Ubuntu Developer Week. All your favourite Ubuntu developers will be there who will introduce you to lots of parts of Ubuntu development including packaging, virtualisation, desktop application testing, development processes, collaboration techniques and lots lots more. This is the perfect time to get started, get up and running and in touch with future team members.

So, what are you waiting for? Go and see the timetable and then see how to attend. I look forward to seeing you all there at Ubuntu Open Week. Oh, and lets spread the word!

The Sessions:

• Patching packages - Martin Pitt will explain the different techniques of patching packages. His session will help you get started with UbuntuDevelopment as it’s a good entry point to improving the software we use every day.
• Launchpad PPAs - Launchpad Hackers Celso Providelo and Matthew Revell will introduce you to a great feature of Launchpad: Personal Package Archives. Building packages for testing and preview reasons made easy.
• Packaging 101 - Daniel Holbach will talk you through the most important properties of Ubuntu and Debian packaging.
• MOTU School - Working with Debian - We’ll have James Westby around, who is very interested in collaboration between Debian and Ubuntu. His session will showcase tools, initiatives and processes to make this happen.
• Introduction to the ServerTeam - Interested in servers and services in the Ubuntu landscape? Matthias Gug introduces you to the ServerTeam.
• MOTU Processes - Interested in becoming a MOTU? Daniel Holbach will explain the MOTU processes: how to get involved and how to get things done.
• Virtualisation - Virtualisation is definitely one of the hottest topics at the moment. Virtualisation Specialist Søren Hansen will talk you through the state of things and answer all your questions.
• Kubuntu - For those of you interested in development of the big K, we’ll have the Kubuntu developers around.
• Ubuntu Derivatives Team - We have new Derivatives coming up almost every day. The Derivative Team aims to make collaboration seamless and help derivatives to get things done.
• Debdiffs and how to get them submitted - Daniel Holbach will showcase one of the most important entry points to get involved: how to produce good patches and explain how to get them submitted for inclusion.
• First steps on contributing (MOTU/TODO & MOTU/TODO/Bugs) - MOTU contributor Nicolas Valcárcel will talk about his experiences and give you first-hand hints how to get started.
• Desktop Packaging Session - Mastermind of the french Desktop mafia Sébastien Bacher will take you on a tour through Desktop Packaging: your entry point to the Desktop Team
• SRU/Security updates - Two of our MOTUs, William Grant and Luca Falavigna, experienced in doing security and stable release updates will talk about exactly that.
• Firefox 3 Extension Packaging - We’ll have Mozilla hacker Alexander Sack around, who will talk you through packaging of Firefox 3 Extensions.
• Writing Scripts For Automated Desktop Testing - QA developer Lars Wirzenius spent quite some time thinking about testing of applications and will take you on a tour through testing Desktop applications.
• Bughelper - making bug work easier - Bugmaster Brian Murray and bughelper hacker Markus Korn are the de-facto maintainers of python-launchpad-bugs and bughelper. Numerous tools make use of the interface and make working with bugs much much easier.
• BugTriage - Pedro Villavicencio has an incredible record of triaged bugs and even managed to give Sébastien Bacher a run for his money. He’ll get you started doing bug triage which is one of the most important points of development.
• MOTU Q&A session - This session has become an institution and happens every Friday at 13:00 UTC. For once we’ll move this to a later time and invite you all to be there. Prepare your questions and let’s get started together.
• Library Packaging - Long-time MOTU Stefan Potyra will talk about the bread and butter of almost all packages: libraries and how to package them right.