Slashdot Mirror
What's Missing from Free Software?
dan.hunt asks: "Klaus Knopper was interviewed here and the interviewer, technobeast, asked: 'If you were asking the questions, what would be the 1st one you would ask?' Klaus answered in part 'What are you missing in the available Free Software, and how would you like to change that?'"
Easy. Source distribution should be optional. If I recommend a free piece of software to somebody in the windows world I want it to come in one downloadable file, with an installer with lots of dialogue boxes.
www.HearMySoulSpeak.com
In Linux.. hardware compatibility is missing.
In Mozilla.. not much is missing.
In Open Office.. Microsoft Office is missing.
Slashdotter are stupid and biased.
he writes that the 700MB are not enough, and with every version he has to dump some programs for others. how about dumping KDE in favor of some other wm that takes less space? icewm and *boxes come to mind.
really I think this is just a function of another, larger phenomenon: with free software there is a great focus on the most common applications but not for niche applications. everyone uses a web browser, office programs, CD recording, audio extraction/encoding/playback, etc. the same is true for server systems: apache, perl, python et al, samba, SQL & friends all fill the voids in a free server system
but until recently, applications that only a few people would find useful have not been available. it's only been recently that linux has become a viable platform for audio production/editing. I think device drivers will follow soon.
it only takes one programmer to write the code and then it can be copied at a marginal cost approaching zero.
What's missing from open source software has little to do with the software itself, but with the approach to it.
Consider a sampling of successful and focused OSS projects: Perl, Python, Ruby, Linux, Apache, GCC, GNU file/text tools. What is it about themthat makes them successful? They focus on a single audience. Perl, Python, Ruby, and GCC focus on developers, and serve them well. Apache focuses on web serving (and, in its subprojects, web development), and does it well. The GNU utilities focus on the Unix user, and provides the expected interface well. Linux focuses on providing OS support for a wide variety of hardware (I am speaking solely of the kernel and its modules here), and does it well.
Now consider some less focused, yet still popular, OSS projects: GNOME, KDE, Mozilla. They try to be all things to all people. This is, indeed, one of Microsoft's (many) failings: for example, Windows attempts to be a home, workstation, and server OS using the same interface, and Word attempts to provide word processing for Grandma as well as document creation for technical authors and collaborative document management for corporate teams and everything in between. They are mediocre for all of their supposed purposes.
Mozilla is a bloated pig because it can be used for so many different things. (I happen to use much of the bloat, but that doesn't justify its lack of focus.) This is why it is being broken up into separate tools, and rightly so.
Ultimately, compelling software is compelling not because of how many people can find a use for it, but how well it serves some particular audience. This is the inverse of the "right tool for the job" platitude: make your tool the right one for some job, not a tolerable one for several jobs.
I will point out what I believe is (much of) the proximate cause of this tendency to lack focus. The mantra "release early, release often" encourages a lack of focus; once a community of users springs up (which is vital for a successful OSS project) they begin pushing and pulling the developers to support this feature or that. One hopes that some of the users will actually contribute code, which means that features that stray from the focus of the tool may be harder not to include than to include. If the developers do not keep a firm grasp of their focus, it will stray.
This is not to say one should not "release early, release often," but that one must maintain focus in the midst of users and contributors who have their own goals. I applaud the mutt team for keeping it a MUA, and nothing more. Sure, I'd like to see NNTP support, but there are perfectly good newsreading tools out there and, instead, mutt development can focus on being the best MUA it can be. I applaud Linus for rejecting innumerable patches when they don't fit his focus for the kernel. Project leads must discipline themselves if they wish to produce compelling software.
What is missing much of the time is honest labelling. At download.com, much of what is called "free" or "freeware" is really crippleware.
That is a valid point, but it is however not open source software you are refering to. The post was talking about the "Open source community" and if you search Freshmeat instead of Download.com you will find a quite different result. Let's not confuse OSS with the crippled spyware you find at Download.com.
Scitne aliquis remedium potimum crapulae?
KDE is not a window manager. It is a desktop environment comprising several libraries, utilities applets, office applications and the KWM window manager.
Consistency.
But the whole nature of free/open software is that everyone wants to do things their way (myself included), so it's something that's impossible to fix.
No one is reaching out to the graphic design community. While they also have a tradition of copyleft, free fonts, and royalty free no cost photography, the two communities simply don't talk to each other.
(Which really isn't all that surprising since both of them tend to look down on each other as worthless parasites.)
I'm sorry, it looks good enough for programmers, but it doesn't look good. And there's a difference, especially if you want the masses to adopt it.
No Zen is good zen
Dear Santa,
We need a robust WINE implementation that permits any shrink-wrapped software bought at BestBuy to be run on any Linux box.
We need OpenOffice to fully support all the heavily-used Microsoft file formats.
We need user-interfaces that can be made to look enough like Microsoft application interfaces that retraining costs are minimized.
In short, we need to address the recurring issues that come up when you ask knowledgeable IT managers,
P.S. I need a high-quality recent-standard-conforming SVG implementation in Mozilla Firebird.
"Provided by the management for your protection."
- Documentation, including *examples*.
- Good UI. For the love of all widgets, *please* take a UI course, before bestowing us with your gift. KDE is looking *real* sweet, but there's 9,000+ other programs that look like crap, and guess what, they aren't as usable as the majority of Windows/Mac programs. Guess there is a lot to be said for a standard.
1. KDE means K Desktop Environment. I guess thats even more descriptive than windows. Excel, Outlook, Entourage, ... all very descriptive. You can't just name everyone of the gazillion open source web browsers "Web Browser", can you?
/etc/init.d/ifconfig start
...)?
2. No, doing things graphically doesn't work for everyone. If people understand what they are doing, they can do most of the stuff that requires a console (which isn't that much, anyways) on the console; if they don't understand that, they probably won't be helped all that much by a GUI.
3.
4. Sure, just convince Microsoft to release the specs.
5. You want to simlify(?) installation by making ppl open up their computer and install a hard disk (jumpering, master/slave,
6. You could always just make symlinks with "human-readable" names to those dirs, couldn't you?
7. Well, Joe Blow. You understand that 2005 > 2003, so far so good. Now imagine a few of those numbers, separated by dots. The most significant number is on the left, and the least significant on the right. Anyways, aren't RedHat et al. doing exactly this already?
Free as in mason.
I'd say the key thing that's missing is speed. Sure, the software that you need/want eventually comes out. However, it takes forever before it does. Part of this is that good software takes good time, and the continual peer review slows down the process. Much of it is also the emulation of existing software packages that take time, since you have to work on something that already exists, so there's a seeming lag.
However, large corporations can crank out huge software projects that are high quality such as Final Cut Pro, Photoshop, Office, Studio MX, etc. Perhaps part of it is also because their programmers don't have to worry about having enough money to eat and pay their rent. If only there were a realistic open source model that's good for the programmer, this would work better. Sure, you can charge tech support, but how many programmers really want to do that anyway?
One thing that is a consistent burden in Open Source software is the raw complexity of the build tools used. What should be an intuitive set of makefiles and header files is replaced by over ten thousand lines of un-decipherable and un-debuggable shell script (configure scripts and libtool). When they don't work, understanding the failure is often nearly impossible, and, frequently, they only work on GNU/Linux systems (so much for portability!).
Everytime I download and attempt to compile something from the source, I get this nagging feeling that there has to be a better way. However, the short-comings of the build systems used could be just a sign that Open Source software still has quite a bit of growing left, and, perhaps more accurately, open source is lacking in configuration management tools, in general. Configuration management is a very complex issue, I admit, considering that package management, too, is still highly volatile and broken (even commercial UNIX could improve in this regard).
Whatever future tools are invented to deal with these problems, I beg that all developers strive to attack fundamental problems rather than use band-aids. Too often, it seems, a well-intentioned developer creates a general tool that appears to solve a problem, but, fundamentally, it only creates more complexity, a higher learning burden, and, ultimately, more well-intentioned tools designed to deal with the earlier well-intentioned tools.
Somewhere, this cycle of naive optimism regarding fix-all tools needs to stop. If a programmer finds that an aberration like a configure script is needed, for example, I suggest the programmer go back to the source code itself and strip out the cause. The program is probably better for it, and we should be brave enough to say "tough doodie" to people that whine about having to actually improve something.
If we continue to let open source decompose into a mess of broken tools, then it is, clearly, no better than anything Microsoft has produced. And, to be honest, when I see the hard-coded path names in GNOME configure files and libtool files, the first thing that comes to my mind is, "Windows Registry" (I hope that offends a lot of people, because it should).
Healthcare article at Kuro5hin
What I have found is missing from a lot of freeware, and even more so from OSS, is the fit and polish that a company writing for profit can give an application. Simply put, when there's millions of dollars at stake, there is a big incentive to add those little nuances and details to the interface and feature set that make a program feel polished, professional and efficient.
COnsistency also suffers when a variety of developers are working on one project. For all the downsides of closed-source, a profit-making company generally has one vision for software, and makes its programmers stick to that. This does generally lead to a level of consistency often unmatched in open-source.
"Reality is merely an illusion, albeit a very persistent one " -Albert Einstein
TeX is great, and LaTeX is a great abstraction layer. However, we lack a mature DTP application which allows us to readily and easily design new documents (newsletters, company letterhead, etc.), especially in a GUI. Scribus is a good start, but we really need something like InDesign.
Also, fonts are a problem. Great progress has been made here (TTF support for X, etc.), but I want a good way to manage my fonts such that my fonts in X are available to TeX and vice versa. I shouldn't have to do 50 steps to install a font for LaTeX and not have it available in OO.
LaTeX, being essentially a markup language, needs to be reformulated in XML (with Unicode encoding) and brought into the 21st century. It appears that XHTML 2 is becoming very LaTeX-ish (markup represents soley the structure of the documents), and styling is done via stylesheets kinda like LaTeX packages. If both were XML-based, translation would be a breeze, and we would have a nice convergence of print and online publication, something that has been very shitty to this point.
I would also like to see categorized font browsing in applications; I want to go to choose a font, choose sans-serif, then choose Helvetica from a list of 20 faces, not having to find it in a list of 200.
Just my $0.02.
I can't count the number of times I've tried to read a man page to get the basic usage of a tool, only to get frustrated by endless pages of options and no examples. Inevitably, I end up searching Google Groups, or Google...
I would like to run one command, or click one button, to install an app. I HATE having to download a variety of libraries to install something. It's stupid.
This should be a universal thing across all distributions. Or, there should be one distribution with all the niceties of Windows. It's just too fragmented and finicky to go anywhere.
"Would it kill you to put down the toilet seat?" -- Maya Angelou
This is a very bad idea. And I say that as someone who uses XML daily, and is generally very fond of it.
A telling example: XML-based configuration files have made my working with XML quite a lot harder. As you might know, XML systems - and SGML systems before them - can use so-called "catalogs" that map public identifiers or URIs to local files, so that when you reference the official location of, say, the DocBook DTD in a file, you don't have to download it every time. In the old SGML days, that was done with a line-oriented catalog file that would contain something like
PUBLIC "-//OASIS//DTD DocBook V4.1//EN" "/usr/local/share/sgml/docbook/4.1/docbook.dtd"
Unfortunatly, in their great wisdom people (namely OASIS, the organization also responsible for the DocBook and lots of other, usually quite good, standards) decided that line-oriented formats are no good, and developed an XML format that looks something like this:
<catalog xmlns="urn:oasis:names:tc:entity:xmlns:xml:catalog "> o okx.dtd"/>
<public publicId="-//OASIS//DTD DocBook XML V4.2//EN" uri="file:///usr/local/share/xml/docbook/4.2/docb
</catalog>
The problem: Try installing a new DTD. It will hopefully have it's own catalog file, that you only have to register with one of the catalogs already known.
For the old variant, all you have to do is "echo CATALOG new_catalog_file >> /some/existing/catalog". Removing it again is easily done with grep -v or sed. Try something like that with the XML format, and it will end up unparsable. You either have to edit it by hand, or use a special program that knows about XML and XML-based catalogs.
In other words, the main effect of the new format is that you cannot use the traditional Unix tools anymore. Manipulating the config files now requires specialized programs, making things like portable install scripts very hard. And I really, really doubt that any GUI or other tool benefits from the XML format - SGML catalogs, and most config files, are damn easy to parse, the hard part is getting the semantics right - what values are legal, what options exist, how to present them to the user in a visually pleasing and intuitive way etc. XML doesn't help you one bit with that.
XML is cool for complex structured documents. Config files are neither documents, nor are they supposed to be complex.
Programming can be fun again. Film at 11.