Discussion on:

The implications of LightWorks coming to Linux

I have been using a technique to do that for the past 2 years.
It is simpler in an OOP environment. In my master object,
I create a new "communications" object that interfaces with
the OS environment. I pass this object to each new object
that I create. Within each object I have a set of "stub" routines
that map to the routines found in the communications object.
In this way all calls within a object are a call to one of the
"stub" routines. The stub routine passes the call to the
OS communication object which actually performs the OS
interface request.

In this way to change the OS environment, all I have to do is
code and test a new version of the communications object/class.

It is a bit of rethinking when you are coding to reference the local
stub function rather than the direct OS environment function.
But once you get use to it, it's just as easy.

I also find it has an advantage that I can use a standard name
for a function that changes across different languages. In this
way I don't have to remember the function is called "len" or "length"
of "size". I don't have to remember if there are differences in the
arguments order, etc. I hide all of those differences in the OS
environment's communication object.

but then, they never do.

as far as I am concerned, if they CANNOT be bothered to have their products run natively on ALL operating systems, they are telling me thier products are NOT WORTH using.

`

As the base of user of linux increases, it would seem a wise move of proactive companies to try and reach out to the user base. Many users who would like to switch to linux are faced with having to find suitable replacements for the applications they currently need.
Therefore if companies move to the OS-independent approach of developing products then they will have a larger target of potential customers.

I am an Ubuntu user. I am also an Intuit user who is still using an '08 product because it is the last one that plays well under Wine (as far as I've heard). I would gladly buy the latest version if it was Linux compatible either natively or under Wine.

Lightworks may well act as a linchpin. Their success can cause others to follow.

This will be good, especially for the software industry. The design discipline this requires will make a healthy competitive market with better software.

...or not... yet. Opposing parties may dig in for a while longer.

Eventually, an open model like this will prevail. The industry is being shaken to its roots. It's just a matter of time...

As @just.a.guy rightly points out, and your article touches on, proper coding which leverages abstraction, inheritance and polymorphism in OOP software architecture designs makes it quite easy to target multiple OS platforms for a software end-product.

Along those lines, it's also important to mention that a developer's choice of language and framework plays a large part in determining to what extent an application is "cross-platform friendly". This is a decision that can and should be made before any code is written, and can eliminate virtually all anticipated cross-platform design overhead if approached properly. It kind of comes down to native / compiled code vs. interpreted / bytecode languages.

It's my opinion that, in practice, the top language & framework candidates for creating cross-platform "traditional" gui desktop programs are java, python, and c#(.net/mono). One can make the argument that there are certain types of graphics and process-intensive programs that do not lend themselves well to this approach for performance reasons, whereby native / lower-level approaches (c, c++) become more necessary. But as the various frameworks have matured, they've become much more efficient and hardware has also become much faster. So, while a quake-like graphics rendering engine has better benchmarks written in native/compiled code, there is still a vast array of programs and types of applications geared toward other types of tasks, where there would be virtually no performance hit whatsoever.

Think about it a moment: if, for example, the quickbooks codebase was written in java, it's doubtful that your average end-user would have even noticed, as the gui could / would be identical. (Admittedly, not a perfect example, because quickbooks may actually pre-date java; I don't recall offhand. Even so, if this is not the case, java was not very mature back during its inception. But you get the point.) Users generally don't care if a program was written in VB.net or IronPython; they only care if it's easy to use, has a good gui, and works reliably and appropriately for the task which they are trying to accomplish.

FWIW, almost all the code I have ever written was done so in a cross-platform way, and it required no additional effort on my part. It's a little frustrating, and quite puzzling as to why more / other software engineers don't do this as well.

Seems to me that big names of recent history Visicalc and Lotus 123, WordPerfect come to mind as examples of ignoring changes in OS - Where are they today?

Windows is a resource eater and it's very slow. I'm using Ubuntu 12.04 and it's impressive what you can do with a four years old computer. Having an efficient hardware usage, I'm also willing to pay and concentrate my finances on buying the application that helps me professionally. After all, I invest and I make money by using it. By using Ubuntu this makes it possible because the Os, office suite , cd/dvd burning application .etc are all free.