Fog Creek Software
Discussion Board

Any Open Source coders?

Has anybody worked on and contributed to an open source project?  If so: which one(s), why did you pick the one you did, likes/dislikes, etc.  If not, why not?  Personally, I've never been involved with one and I don't know anybody who has, although one friend was close to getting involved with Struts.

Wednesday, October 23, 2002

My next-cube neighbour contributed a bug report to the XML Pull Parser project.

The bug was accepted, fixed, and tested in less than 24 hours, and he was duly credited with having discovered it.

Patrick Carroll
Wednesday, October 23, 2002

Oh, and BTW, we're big users of OSS, including:


And we love it.

Patrick Carroll
Wednesday, October 23, 2002

Patrick, aside from the cost, what are some of the things you love?  Does having access to the source code make any difference to you?  Although I don't use it directly, my company uses some OSS on a limited basis (Linux, JBoss, Ant, mySQL) and AFAIK nobody here has used the source in any way.

Wednesday, October 23, 2002

Our company both uses and contributes to Open Source projects.

1. National Semiconductor's DP8381x ethernet controller (natsemi.c) - I just submitted a patch for this last week.
2. Submitted a patch to the kernel multicast layer (accepted).
3. We maintain the "encrypting bridge", which a patch to the kernel.
4. Submitted patches to XFree86.

We use Linux and XFree86 as the basis for our embedded client software.  Unfortunately, some hardware partners don't see the benefit of open source, so the parts I spend most of my time working on are closed source.

One of the FUD myths going around is that you cannot add closed source software to an open source kernel.

Nat Ersoz
Wednesday, October 23, 2002

It seems that the larger open source projects are at least in part sponsored and funded by corporations and mostly worked on by paid programmers.  Is this true?  I think a common impression is that these projects are worked on by long-haired, sandal wearing geeks downing Jolt and Mountain Dew during the wee hours of the night.

Wednesday, October 23, 2002

Our company also use Linux on some of our embedded systems, and we send patches whenever we encount any bugs. Our main work are closed though.

Advantages we've found by using OSS:

- Able to fix small bugs (quickly) ourselves
- Cheap (as in free)
- When having bigger problems, we get fast responses from the developers themselves
- Just as good support (or even better) for general FAQ-type issues

There's one disadvantage though, and that's the fact that some of the applications we use (and are dependent of) are still "under development" (as in not completely stable). But this is not a big issue since there's always a new release around the corner (we don't upgrade unless we need to though).

Wednesday, October 23, 2002

Brian asked: "Patrick, aside from the cost, what are some of the things you love?"

Patrick Carrol said" My next-cube neighbour contributed a bug report to the XML Pull Parser project.

The bug was accepted, fixed, and tested in less than 24 hours, and he was duly credited with having discovered it."

Brian, try and get support of that kind from a company like... let's say ATG (to name one).

I think Patrick's experience says it all, ultimate "interactivity" with the user is a strong point in _some_ OSS projects.

Beka Pantone
Wednesday, October 23, 2002

At work, we rely on a fair number of open source libraries when building our programs.  In general, they're extremely high quality, quite reliable, and have tolerable documentation.

Many of the best open source libraries have paid, full-time maintainers, or at least part-time maintainers who use the libraries in their own work.

We *do* use the source code.  Not often--we typically use it when we need to do some really weird integration, or when we discover a nasty bug shortly before shipping--but it provides unbeatable peace of mind.  Source code is like car insurance: you want to use it as infrequently as possible, but only the foolish would do without it.

In contrast, we frequently despise the third-party middleware we use.  The installation process is generally awful (unless it's DirectX), there's always at least one nasty bug which we're forced to ship, and the vendors range from uncooperative to completely useless.

For building serious, end-user applications, give me open source libraries any day.  Failing that, give me commercial libraries with source code and no per-copy royalties.

Eric Kidd
Wednesday, October 23, 2002

I haven't done much. I use a lot of it, but haven't worked on anything major.

I really like being able to dive into the code. I needed bitwise ops in the SQLite database library, so I added them. The final patch took a different form than what I submitted, but the features arrived.

I know code accessibility doesn't mean much to most people, but that one instance or two where you needed it, it's invaluable.

I've submitted a handful of reports, and a couple less fixes myself. I like being able to say "This behavior is wrong", and then fix it, and have it committed.

I've written some open source software. My favorite part about writing it is getting exactly the right tool for the job. It's always *perfect*. And then letting other people use it. I have the time to do so, and I think it's rewarding to write something that a few people use. I have made mistakes, but if i hear about it, i can fix it really quick. It's good.

Mike Swieton
Thursday, October 24, 2002

I was in charge of an open source project called GXExplorer for over a year. It's a replacement for Windows Explorer/File Manager written using Delphi. For a time it went well but things gradually began to slide. One of the problems was that I started studying in my spare time, so I had very little time for the project. Another problem was that people would pop up, contribute some really good code and then disappear off the face of the earth, which was not helpful when I was trying to get them to fix bugs with their code.

I inherited the project from someone else, which meant that there was quite a large body of code that I was in charge of that I hadn't written - never an easy one. In the end I just dumped everything to do with the project on SourceForge and hoped that someone would take it over. That's where it remains today:

John Topley
Thursday, October 24, 2002

There certainly is a lot to be said for timely fixes and being to at least look at the source code.  At the last client I was at we were having major stability problems with a Java app server, the name of which I'll withhold, not that they deserve such courtesy.  After upgrading to their latest release, we were having to restart the server at least 3-4 times a day due to crashes and unresponsiveness.  After literally months of going back and forth with their tech support they finally sent an engineer to our site.  He had a copy of the server source code on his laptop and he found some interesting code that he was kind enough to share with us.  Peppered throughout the code were boolean "hack" variables.  I don't remember it exactly, but an example would be something like this...

if (sessionTimeoutHack) {

Yikes.  It was painfully obvious just by a quick glance at the code that quick and dirty fixes were just slammed in. 

The next project we worked on was the migration to a different app server.

Thursday, October 24, 2002

That is truly disgusting.  Y'know what...  there is only one reason for code not being absolutely perfect:  Time.  Other than that, there is no other reason or excuse.  What is more abhorent, is that some code can be made perfect given time because it has an analytical basis to succeed.  It is thought out, and given enough time, it will/can be made perfect.  But garbage like that should be tossed and the developers flogged.  Nothing makes me more upset than being tied to 3rd party lamery of that magnitude.

Nat Ersoz
Thursday, October 24, 2002

>there is only one reason for code not being absolutely perfect:  Time.

The only problem with this statement is that there is no such thing as a project on which Time is not a constraint.

I'd like to see an example of what you believe to be 'perfect' software. I'm not sure that it is even theoretically possible to write non-trivial, 'perfect' software.

Thursday, October 24, 2002

That's supposed to be one of the big advantages of open source code: that it's only released when it's done and working, and time constraints imposed by marketing departments and PHBs don't exist.

Thursday, October 24, 2002

Time a constraint?  Of course.  Did I not mention that?  I think I did.

Having state variables like "TimeoutHack" indicates code which is crap.  Low quality code takes more time to develop, not to mention the burden you place on others as the prior poster stated - so you multiply your incompetence woes with crappy code.

There are 2 legitimate uses of the variable TimeoutHack:
1. Buggy hardware.  We have something like this.  When you feed a dirty stream (many lost packets) to one vendor's MPEG decoder, it stalls and fails to generate the proper interrupts.  It might be useful to watch for such a condition with something like TimeoutHack.
2. Buggy 3rd party, closed source software.  You might need a timer to keep track of smoeone else's bad software running off into the weeds.

TimeoutHack if necessary, should be limited in scope and well understood.

If you do not take the position that code must be error free (perfect) from the start, then you will write crap, plain and simple.  Code which is well though out - maintains state only where necessary, has well thought out minimalist interfaces and implementations, and has a strong analytical framework - will approach perfection (error free) more quickly than crap.

Can large software deployed in complex systems ever be perfect?  It is impossible to prove it to be so, and even unlikely.  But if you design and implement with anything less than bug free code in mind, you will generate crap.  Crap, crap, crap.  Personally, I'm sick of crap being passed off as software when its really CRAP.

Nat Ersoz
Thursday, October 24, 2002

I have worked on several open source projects,

- FreeBSD kernel (linux emulation) and installation tools

- gtk/glib. This experience actually taught me a lot about programming. The two guys that initially wrote the toolkit (as a side project for the gimp ;-)), were very methodical, and used object oriented methods in their C code whenever possible.

- ported the initial version of KDE to FreeBSD

- several smaller projects.

My company uses almost exclusively open source software (FreeBSD, apache, Tomcat, PostgreSQL, etc.) to develop our product, which is a content management system written in Java.

FreeBSD because I like their development philosophy better (get it right instead of fast).

Apache because it's the most ubiquitous webserver out there, and generally "just works".

Tomcat because it's the only open source servlet 2.3 container. Before Tomcat we used jserv, which was excellent, Tomcat is not that good, see also below.

Whenever I find a bug (and have the expertise/time to fix it) in any open source software, I send the fix back. This makes me feel better, since I'm able to contribute something back, and also makes my life easier, since I don't have to maintain the fix myself and apply to any upgrades of the software in question when it is released.

Our experience with open source software has been great, we run our servers on FreeBSD which is very reliable. Apache speaks for itself. The only product we're not very enthusiatic about is Tomcat, which is a memory and performance hog, but other than that we are very satisfied, and you can't beat the price.

Ofcourse it helps that we're pretty tech savvy, so we can help ourselves if we have a problem :-)

Marc van Kempen
Thursday, October 24, 2002

I have a bit of code in the Linux kernel (sending/receiving DV video on FireWire cards). This was necessary for my business as the existing DV code did not work.

I am working with an open-source 3D renderer project (Aqsis) to get it ready for production use.

I choose open-source software wherever it is practical. I like the ability to fix bugs/add features myself and run on many platforms.

Dan Maas
Thursday, October 24, 2002

[Has anybody worked on and contributed to an open source project?  If so: which one(s), why did you pick the one you did, likes/dislikes, etc. ]

I released a small open source (GPL) .Net SMTP component that fills in some gaps in the .Net framework:

Anyway, after working on it for the first year in my spare time I decided to take that idea, add POP3 and release it as a commercial component. I learned a a few good leasons from it.

1. Don't be too quick to promise your help to a project. People often email me about helping and then disappear. Remember that your gonna get emails about a project 3 years from now asking why you still haven't fixed that bug if your interest dwindles.

2. Make your release not only for developers but for non developers. I was under the impression that anyone downloading this component would be developers and based my packages accordingly. I didn't create an installer, it was just a basic package that has to be tweaked to work locally a config file, the web server has to be set up manually, etc. Looking back I should have created an installer and better help files.

3. Choose your license carefully. If you release your code under a BSD license and then someone takes it, alters it just a bit, packages it, then sells it for a profit don't come crying to me. It happens.

If I had more time I would probably try to help out with the mono project. I see .Net on Linux as a good thing. I also like the Nunit and Nant projects. Those tools help me code and I think they have good community support.

Ian Stallings
Thursday, October 24, 2002

I'm involved with two open source projects, both in Perl: OpenInteract (web application server) and SPOPS (object persistence framework). Both are on CPAN, have CVS available on Sourceforge, etc. They've been available for about two years now. I've also submitted a couple of patches to other Java projects, but they've been minor.

I think a lot of people are reluctant to get involved for fear the wizards will come out of the woodwork and flame them mercilessly for their shoddy code. This happens, but IME it's the exception rather than the rule. Most projects welcome anyone who has good ideas, especially when the ideas are followed up with code.

Part of the sneaky reason for the joy that greets code is that you've invested the (usually nontrivial) time required to figure out the framework. This means you now have an investment you want to protect, which gets you into a (hopefully) virtuous cycle of not only code contribution but also helping newbies out and letting other people know about the tool, which will bring more code contributions, which will bring more people to help newbies...


Chris Winters
Thursday, October 24, 2002


Are you associate with IOCOMP?

Enquiring minds want to know.

Just wanna know ...
Thursday, October 24, 2002

I think open source software provides a strong incentive to "code pretty". In the closed source projects I have worked on, it is easy to slam in a hack because no one will see it. I think most engineers have pride in their work. If they know people will see their code, then they will do it right.

At my work, we do have some hacky code. The code I work on is very cross-platform, so we must have workarounds for bugs in all sorts of operating systems and web browsers. I estimate that about 5-10% of our bugs are really bugs in the system software we use. Making the code portable is a challenge and a Windows coder will inevitably cause problems on Linux or Mac, but I think the final product is a lot better quality.

Zwarm Monkey
Saturday, October 26, 2002

*  Recent Topics

*  Fog Creek Home