LCA: Addressing the failure of open source [LWN.net]

LCA: Addressing the failure of open source

Posted Jan 18, 2012 18:59 UTC (Wed) by iabervon (subscriber, #722)
Parent article: LCA: Addressing the failure of open source

I think where open source has failed thus far is that it hasn't yet led to end users having the ability to modify their software. To a certain extent, it has led to users having the right and permission to modify their software, but not to the culture that this is something to do, nor much in the way of end-user-level information as to how to go about doing it.

I've joked that Emacs isn't *really* GPL-compatible, because the GPL requires that "the preferred form for making changes" be available, and a lot of it is only available as elisp. But I think there's a real problem when even technically-competent users of GNOME have complaints about the UI in a new version and don't just fix them.

I think that, in order for open source to truly succeed, end users will have to be brought into a culture where the normal thing to do when some application behavior annoys you is to change it. That's the only way to actually achieve the idealistic goals, and the only way to lock in a victory.

(Log in to post comments)

LCA: Addressing the failure of open source

Posted Jan 19, 2012 8:35 UTC (Thu) by ortalo (subscriber, #4654) [Link]

Nice view. I also like the way such an idea blends together tools and end-products.
But, how manage the knowledge/time gap that may exist between being able to use something and being able to build/modify it?
Anyway, from the cultural point of view, you are certainly right. Users need to give value to such freedom instead of being afraid of it.

LCA: Addressing the failure of open source

Posted Jan 19, 2012 11:45 UTC (Thu) by wookey (subscriber, #5501) [Link]

This culture developed for websites and HTML for a while (and resulted in some ugly websites!), but this has been subsumed into other tools now so most(?) website-creators have little or not clue about the underlying tech anymore.

I guess a big part of the success of HTML in this area was that the code was already there in front of you, and ultimately HTML document-writing has a lower barrier of entry than programming.

There is always a significant barrier of entry to programming and fixing your apps. You need to learn the language and the codebase. I don't think we can expect much from mass programming beyond changes to simple apps written in easy-to-read/change languages, as most people really aren't interested enough to invest more effort than that.

Easy app-development is definately key. Arduino and Android have both had wide success at least partly due to programming being made relatively straighforward.

LCA: Addressing the failure of open source

Posted Jan 19, 2012 18:27 UTC (Thu) by iabervon (subscriber, #722) [Link]

I think the key is really that pretty much every application should consist of an easy-to-read/change "policy" layer over a complex core that is less user-serviceable, but also less likely to be the area where the user needs to change something to be happy. For example, graphic designers using the GIMP should be able to change what is in what menu and toolbox to fit their work flow; they wouldn't necessarily be able to write the code for new tools, improve the image representation, or the other complicated things, but the GIMP could be a simple UI app issuing instructions to a complex engine. The answer to "The GIMP's UI doesn't work like I want" should be "Change it. If you're smart enough to use Photoshop layers, you're smart enough to rebuild the GIMP UI from pieces." (And this should, in fact, be true when someone tries.) And making GNOME 3 act like GNOME 2 (so far as the user remembers GNOME 2 and cares) should be entirely within easy-to-read/change code (for that matter, it should be possible to just run the GNOME 2 UI app against the GNOME 3-capable engine; but users should also be able to adopt GNOME 3 functionality by copy-pasting it from the official GNOME 3 UI).