Linked by tessmonsta on Tue 16th Mar 2010 08:55 UTC
GNU, GPL, Open Source Today's mobile space is owned by the likes of Nokia, RIM, Apple, and Google. While some of these corporations have embraced some open source components, a full FLOSS solution has yet to gain traction. Why? Blogger Bradley M. Kuhn posts thoughtful analysis of the current state of Open Source in the mobile space.
Permalink for comment 413980
To read all comments associated with this story, please click here.
Member since:

@Laurence : First, thank you for posting that excellent comment ;) I can't mod you up because of OSnews's unusual rules, but I may congratulate you this way.

I agree with what you're saying in principle, but proprietary software doesn't always get it right either.

Totally true. I tried to install my beloved GIMP on Mac OS X and I can tell that being proprietary-oriented is not the solution to anything. I just say that when bits of proprietary management (not necessary proprietary softwares) are carefully introduced in strategic places, one may get way better results.

Take Windows for example:
* You have a range of APIs from .NET and Win32 through to DirectX. So you end up with half a dozen different APIs that can be used to do the same job.

I don't believe it's true, even though I accept proofs of the contrary. For a long time, Win32 did an excellent job at making applications that just work almost alike. There's a lot more free (as in free beer) software on windows than on linux, but I actually encounter a lot less usability and theming inconsistencies on windows.

It's logical when you think of it : programming Win32 was incredibly easy, thanks to simple yet efficient dev tools like Delphi, C++ Builder, and even VB somewhat.

.Net did indeed introduce some mess, but not until Windows XP. And its use remains quite limited, though slowly rising since the death of powerful Win32 dev environments (RIP Pascal object... Sigh...). Actually, Microsoft are more victims of their own success, now that they face Win32's limitations and try their best to make people move to a new platform when they don't want to.

About DirectX... Did you actually encountered applications which code their interface directly using DX, apart from games ? Games have traditionally non-standard interfaces, on every platform, and customers are used to it, so it's not such a big issue.

Sure, there's some shitty non-standard interfaces (noticeably flash-based ones) on autoruns (that are sentenced to die by microsoft anyway). And on installers too. But most software remains Win32/.Net-based and consistent with other software...

* There's no standardisation of interfaces between the numerous Office versions, let alone Office, Visual Studio, and basic windows apps (Explorer, Notepad, etc).

And that's just Microsofts in house projects.

Totally true that Microsoft, and Apple to a lesser extent, don't know how to apply their own interface guidelines to their softs and look like most software around. Again, proprietary guidelines can't do anything, people must actually use them.

When you take the wider Windows platform you have:
* Java which looks and behaves hugely different to .NET / Win32.

Desktop java applications aren't very common, except in corporate environments...

* countless 3rd party projects that don't adhere to Microsofts UI (often creating their own widgets and toolkits)

And infinitely more that do adhere to it, contrary to the Linux world where we get the reverse picture

* countless application duplication (from professional studio suites to freebie config toys).

Of course, but not at a core level. To say it in a different way, they don't depend on each other in an intricated way. You don't need VLC to mix audio with REAPER, and you don't need GIMP in order to use firefox. Duplication very rarely occurs in the API area on Windows, which is a blessing compared to the multimedia madness on linux.

* several different codecs for the same media (video / audio) file types
and so on.

...and codec packs that install all of them definitely, without needing to get through gstreamer here, xine there, and ffmpeg somewhere else.

The point is, sometimes duplication happens because users like to have a choice of application as different projects tackle the same problem differently. So what might be intuitive for one person might not be as intuitive for another.

Yup ! But again, that's true at a user application level. At a core level, a lot of thing are well-defined and don't need to change everyday. If multimedia and basic UI APIs are well-made, like DirectShow and Win32 used to be, there's no need for a new codec set and massive effort duplication, nor for multiple inconsistencies due to use of several widget toolkits.
Which leads us to your next point...

Sometimes duplication happens because the existing tools available aren't up to scratch and it's easier to start from a clean slate than to fix something that's broken.

I can't agree more ! In order to work, the proprietary development model must offer excellent dev tools to begin with, that devs would want to use instead of reinventing the wheel. This means that :
-Design must be carefully discussed and well-thought the first time.
-Communication is a very important issue, as I told before. The system devs must be constantly talking with the user application devs in order to stay informed about their needs and introduce changes in the API as soon as it is needed, before someone decides to make a duplicate of a system library and make the OS enter a Linux-like hell. Contacting them should be very easy, too.
-Good IDEs and encapsulation in APIs are critical. If you make your own dev tools, you can tweak your OS without the devs even knowing, which gives you extreme freedom compared to other options available.

And sometimes duplication happens simply because developers just fancy a personal challenge.

I don't think OS devs can do something about this one, except using a "recommendation" system like default repositories which make installing software preferred by the OS devs easier (without forbidding use of non-preferred software or making installing it a nightmare though, we're not Apple)

But either way, I consider the variety available for Linux an asset rather than a draw back.

Variety is a double-edged blade. On user apps it serves you. On core APIs, it makes life of OS builders, users, and maintainers close to hell.

The problem is polishing enough products so there's alternatives to choose from if you want rather than alternatives users are forced to investigate because the defaults are buggy.

Yes. Defaults must be good enough so that the vast majority of software uses it, for reasons that should be obvious. And slightly pushed forward to make sure most people will use them. But jailing the user is infantile and inefficient.

So users shouldn't need to know about the different GUI toolkits nor sound engines so long as there is themes / wrappers / etc bridging the differences to make applications and utilities use widgets or sound in the same seamless way regardless of the developers API preferences.

That's my point about standards, proprietary design and feature requests but free implementation. OS builders don't have to do anything all by themselves, and they can't anyway. But if something is likely to be often used, and shared between applications, they should better tell developers how it should look and work. And maintain it themselves if use of it is really extremely common (typical example : basic GUI widgets like windows, buttons, pointers, labels, edits, and so on).

And that my friend is the problem with Linux. NOT the variety, but the lack of coherent compatibility between the different APIs.

Right. But do you know a way to reach that coherent compatibility without a shared underlying proprietary design ? I don't know that myself, that's why I'm all for proprietary design of all core and/or often used components.

Thank you for reading ! Looking forward for any further discussion on the subject, it is fascinating.

Edited 2010-03-17 18:26 UTC

Reply Parent Score: 1