Trelby

http://www.trelby.org

Next time you feel like writing a TV show, this open source program can help.

Devil's Guardpost

Emblematic symbol of Puerto Rico. The devil's guard post overlooks San Juan bay.

Literary Fail

I must say they were not cheering to me, for amongst them were "Ordog"–Satan, "Pokol"–hell, "stregoica"–witch, "vrolok" and "vlkoslak"–both mean the same thing, one being Slovak and the other Servian for something that is either werewolf or vampire. (Mem., I must ask the Count about these superstitions.)

- Bram Stoker, Dracula

Contributing to Open Source Software

I wrote this as a reply in linux.com which I decided that it was blog worthy.

Why are not developers helping out in open source project? I can see several challenges on this.

It's not easy to get introduced and say “hey, I want to code in your project”. Some people will just ignore you, others may not welcome because of politics within the project. If you are an open source enthusiast that have read about the drama of some of the projects, it can be a huge turn off just to get started.

So, Do you want to do your current job in your spare time? Software development is hard and many developers have a 9 to 9 job. Some people just want to do something else than staring at a terminal looking at someone else code after doing it in the office. In many places, it's not Google that encourages to spend work time in projects. If you are married with kids, you need to spend time with them as well. (right?).

Ok, I do not want to sound like a Negative Nancy. I frankly believe that developers can benefit from pitching into Open Source projects. The following might be useful:

1. Document the procedures to get into a project. Many developers might have interest or do not know where to start. Some of them have developed patches that do not share because they do not know how.
2. Cater to the older developer. Some folks that have been working in COBOL, FORTRAN or PL/1 might want to get in newer technology to keep themselves current or just to spend the time in retirement. However many of the projects seem to be run by rowdy teenagers!. It would be bad not to allow these folks to work on these projects. It might be a good experience for all involved.
3. Although money is a factor, many projects they have a paid product to compensate for funds. It would be an idea to entice some of these to join their ranks as a paid employee, if funds allow.
4. Do not minimize contributions. Sometimes is one specific line of code that can make a project crash and burn. I did that on the Mantis project in which one line of code stopped the execution of the SOAP interface in PHP 5.4. I filled a report and it got confirmed. Which conversely, if you find a small but important bug, share it.
5. Although documentation is a problem, it's kind of hard to convince a bunch of hard headed developers to allow you to document the project. IMHO, if you really like the software, just create a “For Dummies” style document on your own and publish it. You can then show the product to the team.

Worst thing can happen is that they say “bletch…” :)


My 2 cents