PDA

View Full Version : Kernels: In-house or leased?


Banana
2006-03-11, 19:10
I'm basically at the stage where I'm learning the inside working of various CADs and sampling various CAD to see what clicks and doesn't.

In the process, I learned that in general, big names CADs develop their own kernels for the application whereas some smaller names lease, from either an independent company or from the big name company and I would really like a programmers/hardware monkeys/computer geeks view on whether having your own kernels is a good thing-

Because this is of interest to a fringe group of a fringe group, there's no interest/demand/need to put out any comprehensive information about ACIS kernel on your average Joe's newspaper so Google is a little short on those kind of info.

To make it practical, I'll use CATIA and Cobalt as an example-

CATIA is made by Dassault System, which bought out Spatial Technology, the makers of ACIS solid modeling kernel few years ago. CATIA has very good GUI, is stable, great for assemblies containing bazillion parts, though it has a tendency to stutter when a part's shape become remotely organic and doesn't really have a good surfacing tools (not that it's needed as it's primarily a solid modeler).

Ashlar-Vellum's Cobalt uses the same ACIS kernel on a lease, but I think it's a version or two behind than one being used in CATIA; I cannot confirm that for sure just yet. It has excelled with organic parts and has even a better GUI, is more flexible in allowing you to draft in 3D while retaining all the parametric information.

Hope that's a good background information for you; I will welcome any parallels or ancedotes from other areas to help me make an informed decision about CAD programs-

So on to the questions-


1) As indicated above, if you lease a kernel, does that mean you will be always lagging behind?

2) Because the kernel is manufactured by someone else with their own set of goals, does that imply a possible incompatibility with your own codes?

3) Using leased codes would mean small firm get to piggyback on big firm's R & D and allow them to concentrate on what *they* do best. True?

4) Would you, as a programmers, prefer to keep your work in-house or have no qualms contracting some works out to people? Under which circumstances would this be different?

I think that'll do for now- Appreciate any insights into this. :)

chucker
2006-03-12, 06:57
You specifically asked me to respond (I've actually overlooked this thread, for some reason), even though I'm not much of a programmer, so I'll try my best. :)

This sounds a lot like the API problem to me. You could ask the same questions:
1) If you use a third-party API/framework/SDK/library, does that mean you will always be lagging behind?
2) Because the ...
and so on.

Your questions are about as difficult and diverse to answer as any political issue is.

My favorite parallel is CD/DVD burning. As of Windows XP and Mac OS 9, or basically as of roughly 2000, the major operating systems out there have had a built-in API to handle burning optical media. This type of framework comes with multiple advantages.

1) If you want to create an app for which burning is a minor feature (e.g. something that, as an aside, allows the user to backup the app's data/database to optical media), the framework will give a uniform interface to accomplish that.
2) There will be plenty documentation for the developer.
3) As users update their system, problems will be fixed and additional drivers will be added for all applications using this framework, automatically.
3.1) Users will pester the OS vendor rather than you in case of trouble. Both in development and in support, you can concentrate on what's important to your app.

But it also comes with multiple downsides.

1) If you want to create an app for which burning is a major feature (e.g. an app like Toast) the framework is unlikely to provide all the features you will need.
2) Adding features may require you to reverse-engineer parts of the framework.
2.1) Reverse-engineering may break compatibility with future versions.
2.1.1) Reverse-engineering may get you in huge trouble thanks to DMCA/EUCD.
3) Users will rely on the OS vendor for added driver support, fixed bugs, etc.
3.1) As users run into trouble, there is absolutely nothing you can do to help them than to point them to the OS vendor or to contact the OS vendor yourself.

Generally, the higher-level frameworks become, the more the application developer can concentrate on what they really want to concentrate on. An extreme example of this is the zero-line browser that WebKit lets you build. But at the same time, there is always a risk that you'll be unsatisfied with certain aspects of that framework. Even if it were open-source, customizations of yours might not be a good idea, as they are likely to break compatibility in the future.

Look at OmniWeb. At version 4.5, it switched to WebCore. They made a conscious decision not to use WebKit, despite Apple's strong encouragement: Omni Group argued that much of WebKit simply wasn't there yet, and they preferred to heavily customize on their own. Where has that brought them? Well, OmniWeb now always lags behind Safari (and other WebKit browsers and programs) by a long shot. This affects performance and stability as much as web site compatibility, and this has, effectively, led to much fewer sales than Omni Group could have had, especially in the 5.x series.

On the other hand, Toast is an example of where not using a framework, even when available, can work. They can look back to many, many years of expertise in implementing burning well, and they do not lag behind Apple's framework in any way; rather, they are ahead of it.

I think that just about covers it. I'm extremely unsure if I adequately answered your question at all, and if not, my sincere apologies for wasting your time.

Have a good Sunday! :)

Banana
2006-03-12, 07:15
That's a good start.

My goal is to learn how to gauge a product's development given on its coding patterns- Nobody will be able to predict the future, but I can say I was a bit wary when I found out that Cobalt was leasing CATIA's kernel, basically their competitior's kernel (strictly speaking, they concentrate in different fields, but there's nonetheless some overlaps). Why not just eliminate the middlemen and go directly to the real stuff after all?

The examples you cited seems to support this as well. Yet, when I consider the features I have seen in CATIA and Cobalt, I'm more likely to prefer Cobalt.

Translating into a job, selecting a CAD program is much like a marriage; you can't just decide one day "screw it. I'm fed up with their dicking around" and drop them and switch. They cost lot of money, requires a subscription service, and then there's that library you built for your most common parts.

Now I've thought about it some more, I should reframe my question; what would be a good predictor of a given product's successful development? Does the leased code impact the possiblity of the success?

Hopefully that has narrowed down the question. :)

chucker
2006-03-12, 07:23
Why not just eliminate the middlemen and go directly to the real stuff after all?

Business efficiency. This is why companies outsource (http://en.wikipedia.org/wiki/Outsourcing). They believe they can save money by letting a third party do the work that they specialize in. At the same time, they lose significant control over the process.

The question is whether that third party can be trusted to actually do a good job. And you can't answer that in general.

Translating into a job, selecting a CAD program is much like a marriage; you can't just decide one day "screw it. I'm fed up with their dicking around" and drop them and switch. They cost lot of money, requires a subscription service, and then there's that library you built for your most common parts.

Like a marriage, you can get out of such a program, too. It requires a lot of effort, and you shouldn't make the decision lightly, but it's not entirely out of question. (Much like you can change your preferred OS one day if you were so inclined.)

Now I've thought about it some more, I should reframe my question; what would be a good predictor of a given product's successful development?

42 (http://en.wikipedia.org/wiki/The_Answer_to_Life,_the_Universe,_and_Everything). ;)

In all seriousness: I don't think there is any. You can look at how the product has done in the past, and you can do some checks on who else is interested in it; chances are if they buy (into) it, they do so for a good reason.

Does the leased code impact the possiblity of the success?

Quite so: depending on how flexible the leased code is, the company may depend more or less heavily on the third party to add certain features.

Banana
2006-03-12, 12:43
Hmm.. Too bad- I was hoping there'd be a indicator or two to gauge a product's future. Not that I was expecting a crystal ball or anything, but I thought that if I at least knew something about their development, I would be able to make more informed decisions.

Besides, my knowing about the leased code doesn't mean I can get to look at the source code and evaluate it directly. (unless there's a mean I'm not aware of)

Nonetheless, I'll post back when I've asked other more experienced caddies if they can do what I was asking above. :)