Fog Creek Software
Discussion Board

Open Source is good

Some people appear to dislike open source ... perhaps because they see it as threatening their jobs.

I'd like to point to an instance of where it seems to work well. I'm currently writing an EKG-related product: contains a lot of data files, and software tools to work with those files.

1) The authors who contribute there are perhaps more interested in solving EKG-related problems than in developing proprietary, closed-source software

2) The interface library (that lets me work with that data) is LGPL.

3) Having the source code meant that I could build the interface library with my latest-and-greatest tool (MSVC v7), which made it possible to invoke it from .NET ... as well as build their utilities (including some antique Fortran source) for my platform using gcc.

4) When I found a bug I was able to submit a detailed bug-report (including the suggested fix) to the author ... and if he hadn't fixed it, I would have been able to fix it myself.

So, what's not to like? :-)

Christopher Wells
Monday, July 19, 2004

>> and if he hadn't fixed it, I would have been able to fix it myself.

That is the problem. I want a tool to do a job. That tool is not as important as the job. If the tool breaks, I want it repaired. Fast. And I am not doing the repairing. If the mainter of an open source project quits, I have to _hope_ someone else picks it up or add it to my already burdened shoulders.

When I pay someone for a tool, I have a legal and moral right to expect that maintenance/upgrade/exchange of the tool be done by the seller. If goes bust, I have a legal recourse which will mitigate my losses, though not eradicate it.

It is not about "open source" vs. "closed source". It is about who fixes the bugs and adds features.

Monday, July 19, 2004

what legal resource do you have against the bankrupt company that sold you your busted tool?

Monday, July 19, 2004

In theory, you should get better support by paying for a product and receiving support from the company you purchased it from.

In reality, support is a cost burden on a company.  After they've sold you the product, they don't really have any desire to offer support.  You have to rely on their goodwill.  Which ultimately, is no different from open source.

Almost Anonymous
Monday, July 19, 2004

5 cents to the dollar? Something? And if the company is big, it is in _their_ interest not to go bankrupt. Enron is bunk.  Its creditors are getting paid peanuts. But you and I still get gas for our cars.

Even then ,so what if he goes bust? Someone else will fill the gap. For money. At higher proces, no doubt. But I'll pay. And then the prices come down. And I'll manage to make a profit.

You are, IMO, thinking about tools for tools, so to speak. Not the end product. In fact, given that 90% of the world's software is in-house, it is "open source" to that extent. But no way Mr. Muppet is going take a peek at my Insurance Management System, that provides that critical 5 extra reports over my comptetors.

If no one produces any Code Editors, Compilers, Profilers, Bug Trackers commercially, I'll not get a "free" version the. At least not without a support system on call. I'll hire Mr. Muppet to produce them for me, at my premises, and *holding him accountable* for any goof-ups.

My Insurance Managment System is my bread and butter. No way I am going to hand over _its_ management to a person who will not be responsible for it.

Now, I am not in the Insurance Software business. But I too am in the "tool for tools" business. Yet, I am not going to hand over *its management* to someone who will not be held responsible.

Put your money where you mouth is.

Monday, July 19, 2004

It's not the religion, it's the evangelists, so to speak.

The open source principles are good, as long as "open source" doesn't equate to a couple hundred programmers running amok like chickens with heads cut off.  It still requires leadership, and proficient architects who make sure the vision stays true, and splinters don't go too far.

The biggest problem is those (both OS and Anti-OS advocates) who go to the knuckle-dragging philosophy that all else is evil, needs to be destroyed, and by golly they'll be the ones to do it.  The result is endless flamewars and one-sided arguments.

"Don't blame the philosophy for those who only claim to adhere to it." -- Somebody, or me if no one claims it.

Conspiracy Anti-Theorist
Monday, July 19, 2004

> If the tool breaks, I want it repaired. Fast.

Yes, so do I.

And I've had bad experiences in the past with big-name commercial libraries: contains a bug, and they wouldn't fix it I don't remember having much recourse ... get our money back ... waste my time developing to that API ... would have prefered to have been able to fix it myself.

My limited experience of open source is as a developer, more than as a user.

> It is about who fixes the bugs and adds features.

In fact the bug I found was in the interface between the antique Fortran and the C library ... and caused by my using a Fortran compiler other than the one for which that interface library was originally designed. In this case the fact that it's open source means that features *can* be added at all ... if it had been closed source, there probably wouldn't have been a Windows version of the thing at all (the authors are more interested in using Unix).

> If the mainter of an open source project quits ...

When I wrote to them I wondered whether the authors were still at the email addresses listed in the source ... they were ... I noticed that they have *.edu addresses.

Christopher Wells
Monday, July 19, 2004

And good for you, Christopher. I have repeatedly emphasised on 'Accountability'. If an OS person fits that bill, well and good. I've noticed that, on the whole, commericial organisations are generally more accountable than 'proud owners'.

And, please MS is *not* the only commericial organsiation in the SW business.

Monday, July 19, 2004

>>> If the tool breaks, I want it repaired. Fast. And I am not doing the repairing. If the mainter of an open source project quits, I have to _hope_ someone else picks it up

>>> When I pay someone for a tool, I have a legal and moral right to expect that maintenance/upgrade/exchange of the tool be done by the seller. If goes bust, I have a legal recourse which will mitigate my losses, though not eradicate it.

The advantage of open source would be that you should - in theory - have a wider choice of people who can fix the software you rely on.  You have the source code, you can hire someone to work on it.

With a commercial product, you don't have that option - if the company refuses to give support or goes belly-up, you may have legal recourses, but those won't immediately get someone working on fixing the software.

If you really depend on it, you probably are better off, as you say, having it done in-house.  But in that case, you might still benefit from using open-source and having an in-house person customize and maintain it.

Monday, July 19, 2004

I'll chime in as well with my own experience.  I once dedicated a month to setting up the new corporate mail server, a system designed so that an email account wasn't also a system account, at a time when this was a pretty revolutionary concept.  We used a custom mail client for a variety of reasons, and depended on a third party IMAP component.  A commercial component, that I spent a month working with.

Said component would occasionally choke in transactions, when the IMAP server sent untagged data (the IMAP standard allows for this, and many servers use it to announce new messages).  We called the company. They were very sympathetic, but they weren't going to fix the problem, not in future releases, certainly not in a bug fix release.  We were left with two choices, neither of them any fun: abandon the month's development, or move to the expensive commercial server that they designed the component around.

We wound up moving to the new server, because nobody, especially me as the developer, could swallow the idea of another month of development with a new component with no assurance of success. Fortunately we were in a position where we could do that; enterprise wide email didn't exist yet, just departmental servers. If we'd been deeply committed to something like MS Exchange, we would have been stuck with finding a new component.

All the righteous indignation in the world wasn't going to get the component fixed.  We were forced to change our server to one that wouldn't send untagged data, which actually removed some features from our mail program.

We would have been smarter to use the open source c-client libraries, which by definition conform to the IMAP standards. Development might have been slightly slower to account for the fact that I was the most skilled C developer in the company, and I was pretty green at the time.  But we wouldn't have gotten the shaft on our purchased component, wouldn't have been required to spend several additional thousands of dollars on the new mail server, and changing our client to deal with the new server.

Clay Dowling
Monday, July 19, 2004

In an earlier project we had a similar experience with using email libraries from Netscape:

*  Yes, there were problems that we neeed to fix (and, yes, some of these were due to "unexpected" data from the email server, or from the client that created the message)

* Yes, it was us who had to fix them

* And, yes, because we had source we were abe to fix them.

Christopher Wells
Monday, July 19, 2004

>> and if he hadn't fixed it, I would have been able to fix it myself.

I still haven't gotten an answer to this question:
You fix an interface issue in one module, add a display enhancement in another, add some custom fields, and make some various performance tweaks you've noticed along the way.

Now version x.8 is released, which fixes your interface issue and is an order of magnitude faster than the previous version (even with your tweaks)

How do you deal with the fork?


Monday, July 19, 2004

Philo, is that assuming the maintainer a) refuses your patches, b) refuses to give you a reason and c) refuses to take your money to maintain a custom branch?

Tayssir John Gabbour
Monday, July 19, 2004

"When I pay someone for a tool, I have a legal and moral right to expect that maintenance/upgrade/exchange of the tool be done by the seller. If goes bust, I have a legal recourse which will mitigate my losses, though not eradicate it."

You know, people claim that open source zealots have lost their grip on reality, but anyone who thinks that purchasing a license to use a copy of a piece of software actually gives them legal and moral rights to have the bugs fixed has to be insane.

Don't you read all the posts agreeing with Joel when he says that noone should ever fix bugs unless they're actually getting extra money from putting that effort in?

If the seller of software goes bust, you lose - you have no rights, no recourse, and it's still not actually permissable for you to make any effort to fix the problem yourself. They might appreciate the opportunity to sue you and get some money to help pay their bills, though. If they decide to demand you pay for the upgraded version with the bug fixes, then you either pay, or you lose.

I'm amused by one thing, though. Apparantly if a closed source software developer goes out of business, at least you can always hope that another developer will sell a suitable replacement and that's great, but if an open source developer stops maintaining the product then you can do it yourself, pay someone else to do it, or hope someone else takes over - and this is absolutely terrible.

get a grip? no? cool.
Monday, July 19, 2004

> How do you deal with the fork?

That hasn't happened to me much, but I'd guess:

1) Ignore v8 and stick with v7 (which, having made my changes, is now good enough for me)

2) Submit my v7 changes to the author (so that, when v8 comes back, my changes are already included in v8)

3) Merge my v7 changes into v8: either, semi-automatically (using my source code version control system, which should be able to merge changes made to the v7 branch into a newer v8 branch); or, manually (which isn't too bad either).

Christopher Wells
Monday, July 19, 2004

Interesting read:

The Success of Open Source by Steven Weber

Monday, July 19, 2004

> How do you deal with the fork?

This is a good point. Open source is clearly inferior to the Microsoft approach, which is "you won't pay us $200 million? There is no fork."  :)

No, seriously, forks create maintenance issues, and not being able to fork can make it harder to fit a component into a new situation - both options have their costs and benefits. The interesting thing is that one group has the option but not the requirement to fork, the other does not even have the option.

If this turns into another round of "it's not always a good idea therefore it shouldn't ever be done" then I'm going to, well, er, not be very surprised, actually.

how do you deal with no spoon?
Monday, July 19, 2004

It always struck me that Open Source is to commercial software what a store is to a flea market/swap meet.  I mean, if I want something I can go purchase it from a commercial vendor at an appropriate price.  Or, if I wish to, I can go to a flea market and perhaps find something.  It really depends on how badly I need it and what I'm willing to do with it.

Open Source is great for enthusiasts of software.  We like to tinker, and we putter, and sometimes we even produce great software, but it's only at a whim.  Commercial software is beholden to its customers and shareholders, and must be satisfactory.

Open Source is great.  It's produced some marvelous pieces of software and makes some companies pretty well off (just like the guy who owns the lot where the flea market is held :)).  For most of us, it's a way to become involved in something we're interested in and make a contribution.

But it's not commercial software.

Poor Analogies R Us
Monday, July 19, 2004

"Commercial software is beholden to its customers and shareholders, and must be satisfactory."

wow that gave me a good laugh.  I actually had the whole coffee coming out of my nose thing :)

classic, absolutely classic.

seriously though, a lot of open source software *is* being bundled commercially now.....apache, Linux, mysql, the list is staggeringly long and Ive only listed the 'bignames'
look at joels most recent post...a lovely little commercially available solution built on top of good, solid open source code.

<g> ...or maybe it was crappy, bugridden open source code, I dont know cause Ive never used it....

but the point is that increasingly opensource code is having interfaces put on top by commercial companies and resold (Suns Java Looking Glass is another good example)

There is *nothing* inherently dodgy about open source code...the only difference between it and commercially available closed source code is that the closed source code is more likely to be easy to find.....if I do a search for any non-specific product the chances are good that Ill find the closed soruce software more easily (with a few 'web server'... where the open source product has been so overwhelmingly popular that it has popped to the surface above its closed source counterparts.

Monday, July 19, 2004

I separate OSS from GNU.

OSS can be a great asset for small a small ISV.  It allows me to get a tool for free that would otherwise cost me a bundle. Yes, it may have some limitations and/or bugs but if it is a tool I only need occasionally then I can live with it.

And example is GIMP. I need to edit images every so often (maybe once a month) and GIMP gives me a good set of tools for free. Photoshop is much nicer, but I can't justify a budget for it when I use the tool 15-20 minutes a month.

The problem I have isn't with OSS, it is with GNU/Free Software Foundation types. These are the zealots that have give the community a bad name.

Why do I dislike this guys? I can sum it up from their original FAQ (paraphrased):
Q: If software is free, how will programmers earn a living? What motivation will there be to create software?

A: A tax will be added to all computer rated hardware. This will be collected by the government [NOTE: I've read other version that use U.N. in place of government] and paid to developers in grants. 

Oh, a tax? Great. Because the National Endowment for the Arts does such a great job with art we should do the same with software? Good idea. Now we can have that Piss Christ screen-save we've always wanted.

Monday, July 19, 2004

Regarding your interpretation of the FSF FAQ: where do you find that??

I could not find it at either nor

Monday, July 19, 2004

Money and cash receipts do have an advantange.

We wanted this Widget X a while back. Umpteen open source versions, and fewer closed source versions. None of the OS versions were charging money, none of the CS versions were free. Pretty much the standard, I must say. So we got one of the OS ones. It worked like a charm. We forgot the whole thing.

This year one client wanted feature Y that can be had only by using widget X. We started to use the OS version we had used earlier. Did not work. Platform changed, design of the application changed. Can't blame the widget. But business is not static.

Now, do I spend time evaluating other options, again? Budget for a developer to 'fix' it? Get in touch with the maintainer? I got in touch. No response. 2 weeks. My lead developer just could not get his head around a new language, a new style, to add features/debug Widget X. We decided to spend money.

Solution. After the third week, we bought a commercial version. It took 4 days to ship the new features to the clients. My client paid me. My supplier got paid by me. I pocketed the difference. Feature Z was requested by my client. A query was raised with the supplier. They gave an answer along with an invoice. We gave an answer to the client along with our invoice. They paid. We paid. As the primary business owner, nothing pleases me more that someone paying me to pay my bills.

My employees work for me. Anything to do with my business, they have to account for every line of code. Personal projects, academic research, pure fun, all that is fine and well. But if it has to be incorporated into my products, I must know, a) will I get more than what I pay - that includes time, effort, lost opportunities *and* money. b) who is culpable for any failure.  I am presuming and equivalence in quality.

Tuesday, July 20, 2004

If this turns into another round of "it's not always a good idea therefore it shouldn't ever be done" then I'm going to, well, er, not be very surprised, actually.

Nope. I'm just asking the question. Generally I see "well if you need [x] fixed, you can fix it yourself" thrown around *very* cavalierly with no mention of the potential impact of doing so. Wouldn't it be more intellectually honest to say "as a last resort, if you have the source code, you can fix it yourself if you're willing to fork the tree"?

I think it's kind of like saying "if you run out of disk space, just buy a SAN" without acknowledging the process may be a *bit* more complicated than writing a check and plugging the box into a USB port.


Tuesday, July 20, 2004

Philo, I suppose that does not come often, because in this respect, both Open Source software and commercial software are on equal grounds.

If it's complex to do, it'll cost you an arm and a leg whether its open source or not.

If it's simple to do, open source is going to be cheaper to solve.

I've found a bug in an open source library I use. I debugged it, fixed it, sent the patch (part of which was accepted, part not) upstream. I still maintain my port for the unpatched part, and since I update often from CVS, I have no problem maintaining my own fork.

I found a bug in the Windows kernel, spent many hours diagnosing it (because it's a black box in most respects for me), and came down to a race condition between the local NTFS system and the redirector. I'm not even sure who I can talk to, as this race condition is extremely hard to come by, and I can only reproduce it in very specific situations (don't have the hundreds of hours needed to produce it with a simple 10-line program). What recourse do I have?

Also, as I mentioned at least twice in this board, I'm entirely UNsatisfied with Windows handling of time, specifically with its precision. I have no recourse. With Linux, I can (and have, some 6 years ago), tinkered with the clock tick mechanism. Indeed, it actually harmed system performance in many ways, but I needed the precision and was willing to pay for it.

I'm mentioning only Windows, because that's almost the only non-open-source thing I use (I use a few more niche products, but the names wouldn't ring any bell).

Mr "." - Your description is too vague to make any sense to me - could you please reveal at least some of the X, Y, Z variables?

Ori Berger
Tuesday, July 20, 2004

Ori, It was a CD/DVD tool. The features were for adding sub-menus, subtitling and componentisation (to coin a word) of those functions to add those to our software. For various reasons, I am not able to provide you with names. Do forgive me.

Tuesday, July 20, 2004

> If the tool breaks, I want it repaired. Fast

Then I hope your schedule corresponds to the vendors release schedule, otherwise you are Fucked. Yes, with a capital F.

Tuesday, July 20, 2004

what part of commercial software licenses generally gives you a right to demand to get things fixed?

OS developers, like commerical companies, consider good will.  Support is just that.  I'd rather chat to the proud OS developer and get something fixed any day.

And as for Joel's frontpiece; if Lookout was open source, is he interested in forking it and keeping it going?  He could..?

i like i
Tuesday, July 20, 2004

*  Recent Topics

*  Fog Creek Home