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.
Thread beginning with comment 413866
To read all comments associated with this story, please click here.
Neolander
Member since:
2010-03-08

I think that open source is a mixed bag.

Open source philosophy is pure genius. Anyone caring about hobby developers should open-source its code, in my opinion. I'm working on a little OS right now (will let you know if one day it's able to do a bit more than switching processes and allocating hardware resources), and having a huge load of documentation and low-level code around is just fantastic.

The idea of software development to which anyone may contribute is also great. The fast evolution of Linux and FOSS in the latter years shows that more than anything else. Gimp, VLC, Blender, Inkscape, OpenOffice.org, Code::Blocks, Firefox... They're more or less innovative, but they're all serious and very powerful software, and I'm glad I have them around.

But this approach has its drawbacks, too. Look at the mess of audio APIs in linux. Look at multimedia infrastructure globally while you're at it. And let's not look at the X11 and graphical toolkits mess.

Open source works great when a project is working on software made to address a specific problem, with a well-defined design and feature plan. It looks less good when people try to put that software together and make a complete desktop environment. Inconsistency and effort duplication occurs in the best case. Stability issues in the worst.

I think that open-source OSs needs some central management. The implementation of most parts of the OS can be made by the community, but design goals and feature requirements for each of those parts should be at least partly stated by a relatively small group of people which may meet around a large table every month and discuss it for 4 hours. Yes, that's the way proprietary software works, except once you get the scope statement, you can implement it the way you like.

Let's say you've got an OS that's fine at browsing the web, but now some guys want to play HTML5 videos on it. Modifying the web browser, the multimedia framework, or the UI alone is not possible, some cooperation is needed.

-The proprietary way of doing things is when you own anything from the browser to the kernel. You take some times to design things, modify the browser, modify the multimedia API of your system, modify the UI management part, and are able to read HTML5 videos.
-The Linux way of doing things is that somewhere in the wild, a guy in a garage introduces a brand new browser that, thanks to a multimedia framework developed by two Polish guys which doesn't support a single codec yet, may embed videos. If you're lucky, some people get excited about it, and a new browser and multimedia framework are added to the huge pack of those available on Linux. After months of duplicated work, it's finally usable.
-In my opinion, the best option is that the OS manufacturers think about it, and find out how software should be designed in order to allow HTML5 playback. Let's say it's about multimedia player embedding capability in the UI widgets. They describe on their wiki how the UI widgets should be modified to allow these embedding capabilities, then kindly notify the people working on the UI widgets that they've got some stuff for them (or do it themselves). They then notify the browser makers that the UI meets now all requirements for HTML5 playback.

This requires good public relation skills and cooperation between system managers and applications developers. But IMO, without minimum central management and standardization like that, FOSS cannot meet the interface consistency and reliability requirements of modern software.

Edited 2010-03-16 17:39 UTC

Reply Score: 0

lemur2 Member since:
2007-02-17

Look at the mess of audio APIs in linux. Look at multimedia infrastructure globally while you're at it. And let's not look at the X11 and graphical toolkits mess.


On any one Linux system, there is no mess. On my Arch Linux KDE 4.4 desktop install, there is no "mess of audio APIs", there is one. There is ALSA at a lower level and Phonon at the device-indepentdent level. There is also one GUI graphical toolkit ... which is Qt.

On a mobile device running Android or Meego, there would be a different set of audio APIs. Meego has the same graphical toolkit as KDE 4.4 desktop (which is Qt), but Android has GTK. However, Android is NOT the same system as Meego, and both are NOT the same system as a KDE 4.4 desktop. No machine would run two of these OSes, and the devices which would run the OSes have different uses.

Reply Parent Score: 2

Neolander Member since:
2010-03-08

@lemur2:You may get this result, but only provided that you chose to use only <X>% of Linux software capabilities.

You talk about using only Qt, but then you have to give up on GIMP, Inkscape, Emesene, Ardour, Firefox...
Conversely, those who want a GTK-only desktop give up on Kile, Rosegarden, Qtractor, KTouch, Opera, QJackCtl...
You want to use only ALSA + Phonon ? Fine, then you drop almost all high-end audio software on linux, they rely on Jack.

Please correct me if part of this is outdated, I don't check package dependencies everyday. But I think most of it is still right as of today.

Basically, choosing to use Linux in a non-messy fashion is dropping, say, 75% of powerful linux software. One day, you might need this software. And then you'll have to make your system more messy or switch to another OS. That's my problem with Linux. I prefer it over other options*, but like OS X it definitely IS a mess when you try to do a little more with it than playing Minesweeper.

*Except sometimes, like when I find out that my distro have pushed forward that broken dmix duplicate called Pulseaudio again and that there's no more sound in the new release.

Edited 2010-03-17 06:24 UTC

Reply Parent Score: 2

Laurence Member since:
2007-03-26

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

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.
* 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.

When you take the wider Windows platform you have:
* Java which looks and behaves hugely different to .NET / Win32.
* countless 3rd party projects that don't adhere to Microsofts UI (often creating their own widgets and toolkits)
* countless application duplication (from professional studio suites to freebie config toys).
* several different codecs for the same media (video / audio) file types
and so on.


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.
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.
And sometimes duplication happens simply because developers just fancy a personal challenge.

But either way, I consider the variety available for Linux an asset rather than a draw back.
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.
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.

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

Reply Parent Score: 2

Neolander Member since:
2010-03-08

@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