Older blog entries for guerby (starting at number 1)

It might be of interest to some advogato readers (let's fill these diary entries a little bit ;-). As I said in a previous message in the thread, I would love to see what is the current employment ratio of shrink wrap vs custom software + support, and money making ratio, and David answered he would love to see it too. Any information?

From: Laurent Guerby <guerby@acm.org>
Subject: Re: Why open source is winning
Newsgroups: gnu.misc.discuss
Date: 21 Oct 2000 13:07:51 +0200

Laurent Guerby <guerby@acm.org> writes:
It looks like to me that you're reducing the "software development industry" to the "shrink wrap proprietary software industry".

David Masterson <dmasters@rational.com> writes:
Is there any other? :-)

Well, none of the people I graduated with (software engineering) work in the shrink wrap industry, they all work writing/maintaining custom software for big projects, or as contractors inside various companies also developping/maintaining custom software for one client. All these companies and people are making big money, and there's no shortage of work to do!

It might be an Europe vs US way of doing software.

I would say you're missing all the one customized software for one customer/problem industry [...]
I mentioned this later in my message as "contract" programming (ie. first user pays development costs). Its not an unreasonable model, but it does have flaws...

But you seem to imply again that all software is "sellable" to the masses (shrink wrap), and that's just not true. I see a large market for "first user pays development costs" and no other user ever exist.

But, of course, you're thinking like a bank employee with no competition for your job.

Just to clarify what I do, I work on financial equity and other derivative software, if you think there's no competition for jobs or otherwise in this market, I guess you don't know it at all!

Now think about it from the point of view of the bank. What would the bank think of making *ALL* of the software that you develop "open source"? Can other banks now become more competitive with your bank because they pick up and use your software? Remember these other banks are not obligated to contribute to the development of the software, so they would be making use of your software for "free" (monetarily speaking).

I think you're completely misunderstanding the "open source" licensing scheme. You're NEVER obliged to release to the community your customization as long as you don't distribute binaries to people outside your organization (*). There are custom ports of GCC made and used by only one company, and they don't have to release it at all, and this is perfectly fine with the FSF. The software I work for is not intended at all for use outside our company, and we even have some software protection and authorization scheme to make sure it stays this way.

(*) There is some debate on how to have multi company collaborative work on "unreleased" GPL software, but that's a bit special.

On the other hand, if your software is *not* released as "open source", does that mean that all those other banks have to go about duplicating your efforts? Isn't that wasteful?

Yes of course all other banks in this market are duplicating our efforts, this is where the competition is! The software embodies nearly all of the bank derivative product know-how, that's all kept secret as much as possible. The model is that if you want to know what other banks are doing, you have to pay to get their employees work for you and bring you their knowledge. There are companies selling this kind of software (proprietary way, and may be open source way), but with much less advanced functionalities (often with a plugin interface so that banks can put their know-how in).

Perhaps it would be a win-win if your bank sold the software to the other banks (oh, but then you're into a "proprietary" model... ;-)

See RISK magazine if you're interested in learning what's going on in our industry.

My employer decided to use an open source tool and pay for technical support (not cheap!) a few years ago for this critical piece of software and this was an informed move. They hired me in part because I know very well the technology since I worked on it, and the sources are available. In case of emergency I'm even able to fix things myself (we have very hard requirements on getting things to work quickly). They can't get that level of insurance if they choose to use proprietary software since the selling company is the only one with source access (monopoly), if you piss them off and have a problem, you're dead, no alternative, no incentive to fix things we need (except may be the low one to one 1/N with a big N since you're selling to the masses). To put it otherwise, vendor lock-in and racket.

For other custom software developed in my bank where multiple proprietary tools are used, my coworkers have to make sure things work together, and sometimes their vendors have conflicting interest, I can tell you that ends up being very costly and unsatisfying.

I guess this experience applies to other industries, a lot of businesses today are heavily depending on combining and customizing software for their own unique purpose. If your business scales up, you'll end up being very interested to buy skills to do even more customization, and in this way, open source is very attractive because it is ... the only option. Sometimes you might even end up competing in a slight way with what your original vendor software does, and you just can't live with a proprietary vendor.

I firmly believe that the software market needs this kind of competition, and I do not see it at all as putting every software engineer out of business, well on the contrary! But I can easily imagine that people with different experience think otherwise.

PS: I didn't notice your email at first, but your company is offering a competing product to the free software we use (GNAT, an Ada compiler). I haven't tried yet to compile our software using the Rational Ada compiler, but I'll do it one of these days, as QA for code portability at least ;-).

Laurent Guerby <guerby@acm.org>

Just a note for those who find "The Future of Programming" advogato post interesting: you might have a look at the book "High Integrity Ada" by John Barnes (Addison-Wesley), it describes a safe "provable" subset of Ada 95 known as "SPARK 95". Also look at the message of Peter Amey in the thread "High integrity software" of the comp.lang.ada newsgroup for some interesting claims.

Formal proofs are in use today with existing languages for non-trivial software, it's just not C/C++ (as the cvsup author John D. Polstra wrote it's "notC" ;-) and what can be called a typical hacker environment and mindset. Needless to say I regret this a lot, in particular the Ada entry of the Hacker's dictionary is highly misinformed ;-).

As for proving with C, it's uselessly hard because the pointer model is pervasive. And for the C++ template model, AFAIK, it does not even enforce interface and implementation separation which is quite essential for scaling up (you need to know all the implementation code to see if your template use will work).

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!