Open Source for Dummies? 46
GNUpowerSoul asks: "I have been working for several years on a large open source library. Ever since we made our first public release three years ago, we have found that the majority of our users seem to have no experience whatsoever with open source ideas and conventions. We have had to dumb down our documentation considerably (to the point where we have multiple pages to describe in excruciating detail the usual 'configure; make; make install' step). Has anyone else had experience in how to deal with a user community who doesn't understand the 'normal' practices for open source projects?"
One good example... (Score:4, Funny)
Unix (Score:4, Informative)
i got a better idea... (Score:4, Insightful)
Re:i got a better idea... (Score:5, Insightful)
WHOA!
Users and 'configure; make; make install' do not go together. Unless, of course, by "user", you mean a developer foriegn to open source conventions. This would most likely include non-Unix developers.
While it is appropriate for users to compile and install their own open source software, like the parent points out, this should happen automagically for them: insert CDROM, click "OK", watch it compile and install (or not and offer to email the build log to the development team).
If your audience are developers not familliar with open source conventions (and, by extention important licenses like the GPL), then, yes, technical things like "here's the standard way to build" a package should not faze them (unless, perhaps their microSofties that have never seen the outside of Developer Studio.
Re:i got a better idea... (Score:2, Insightful)
Of course, typing any commands in isnt always the most end-user friendly way of doing things.. which explains the existence of the myriad of GUI package management tools.
Person
Re:i got a better idea... (Score:2)
1. Package managers. Yes, package managers are supposed to help deal with these kinds of issues. So, why not start with the .configure; make; make install description and then go on to discuss the various efforts to simplify this, letting the user know, at least a bit, of what goes on under the hood, when dealing with source packages.
2. BSD ports. Oh yes, great idea. Trouble is, that it is developer-centric: the front end is "make": which not only builds and installs
Re:i got a better idea... (Score:2)
ad 2: The primary font end for the ports collection on FreeBSD is "portinstall", which is hardly any harder to grasp than rpm or apt. Of course, if you use another BSD or don't want to wait for your software compiling, there's always pkg_add, which will be happy to download the package from a well-k
Binaries take server space (Score:1)
Have a developer do the 'hard' work of compiling the program and resolving dependencies, shipping it out as a binary package
For a small operation, renting HTTP[1] server space to hold binaries for 20 different platforms can be prohibitively expensive unless the application is designed to run only on Microsoft Windows operating systems on x86 computers.
Re:Binaries take server space (Score:1)
Of course, the best solution is user education, perhaps instead of writing 4 pages of how to do an install step, poin
Re:i got a better idea... (Score:2, Funny)
Whoa. Clock me! Nine months using Linux exclusively and I have become an elitist!
Set your stop watches for "hacker" and watch me go again.
OK, here is my problem (Score:4, Interesting)
'click start' then click settings' and click on the control panel... well, start is the button in the lower left that says 'start'... no, its not a button on your PC, its on the screen... yes, I am sure its not a button on the front of your computer...
Anyways, you get the idea. Make it simple, or at least someone out there make a basic guide on things that most instructions take for granted!
Re:OK, here is my problem (Score:3, Interesting)
I don't mean this in a bad way really, but you are the person that's touted by microsoft as always being cheaper to hire in those TCO studies we are innundated with. Rather than someone wit
Re:OK, here is my problem (Score:1)
Lesson learned..
Reading the manual but not understanding it (Score:1)
Any problems after you install without referring to the stuff that comes with says one of two things:
So how do you handle those people who do read the READMEs, FAQs, and HOWTOs but fail miserably to understand them?
Re:OK, here is my problem (Score:5, Funny)
Re:OK, here is my problem (Score:1)
Open Source-ism? (Score:3, Informative)
So if your problem is really 'How do I teach newbies to compile on a *nix platform?', then I would recommend, say, Building and Installing Software Packages for Linux [help-site.com].
On the other hand, there's the ever-so-popular 'RTFM', or the only slightly less popular 'no response', both of which have a long history in open source.
Yup, it's a GNUish Unixism.... (Score:5, Insightful)
Download software.
Search for documentation - find incomplete and poorly written docs that assume too much.
research and correct 15 badly documented error [choplogik.com] conditions.
identify 3 totally undocumented errors [choplogik.com].
join project mailing list and post question.
be roundly flamed and referred to FAQ
post references showing errors are not documented in FAQ
be roundly flamed and referred to list archives
search list archives for several days
post again asking for specific references to archives
Acerbic but kindly guru finds comment written in swahili that is only in the CVS version you can't access, and translates it for you in a private Email.
remove a single character from the configure script
edit the makefile to correct unwarranted assumptions about file locations, system capabilities, network architecture, etc.
make
correct typos introduced by prior editing (D'OH!)
make
research and correct 7 errors [choplogik.com] caused by missing libaries (these libraries are normally required only by Welsh Morris dancers, but for some reason your GNU software won't compile without them).
make
research and attempt to correct 3 errors [choplogik.com] caused by having a different version of gcc than the software authors.
make
give up on correcting the errors and go download the precise version of gcc used by the developers.
make
cheer like nobody's watching, which they aren't because it is five O'clock in the morning.
make install
Congratulations! You have sucessfully built your GNU software. This amazingly powerful software will now run incredibly smoothly and accurately for unbelievable lengths of time. (Unless it's a 2.4 linux kernel, in which case it'll be obsolete by Monday when the latest remote root exploit comes out, or whenever Linus decides to replace a major subsystem wholesale in the middle of a "stable" kernel series.)
After a few years of living comfortably with your smoothly running, reliable, low maintenance GNU software, you'll break even on the pain and suffering quotient.
I recently configured heartbeat [linux-ha.org] and I've done most of the uber-GNU utilities that don't deign to have man pages (info is so much better, the only way it could be more user friendly is if it required all input in Common Lisp) so it's just barely possible I might have some idea what I'm talking about. On the other claw, I may be stark raving bonkers from too many
+1 funny; +1 accurate description [no text below] (Score:2)
re: Open Source for Dummies? (Score:1, Funny)
Provide binary packages (Score:2)
NEWSFLASH! (Score:5, Insightful)
The usual 'configure; make; make install' step should not exist! This is the single most awful thing about Linux. God help the user that has a dependency problem.
Binaries should just slide on in. At worst your install program should do any voodoo required.
Ready to be modded into oblivian now,
Bill (who started on V7 Unix thank you very much)
Re:NEWSFLASH! (Score:2)
The purpose behind these steps is to allow portability among Unix platforms. The configure step does a number of things, including determining what OS you are using.
However, I think there is a place for a standard install tool. Perhaps one that can understand enough Autoconf to give the user a selection of options, then do configure;make;make install. Then the user can use any autoconfiscated software, and have a ni
Nope, It's the Users... (Score:4, Interesting)
The single most important concept in Unix is that there is ONE TOOL for every TASK. The "users" you refer to (hopefully we're talking about administrators) think that "compile and install program" is one task.
For Open Source programs that one has to compile, there are actually three tasks: configure, build, and install. For closed-source software, you have already paid someone else to perform the first two tasks for you, and lost quite a bit in terms of configurability in the process.
With Open Source, you get to control everything from configuration to compilation to installation. The downside to this flexibility is that for poorly-maintained projects, it doesn't always work. Separating the process into three distinct steps can also help the administrator to diagnose problems with the install.
Strike that, reverse it. (Score:1)
Re:Nope, It's the Users... (Score:2)
It always seems more like 18 tasks because there are always at least 5 specific versions of libraries or libraries you don't have installed that must be configured, built, and installed before the program you want to compile can be.
Apple users meet Unix... (Score:3, Informative)
...and the result is fink [slashdot.org].
Really, the situation you describe is very similar to what the oldtime Mac-heads who like OS X are going through. For many examples of how to boil down these kinds of instructions, see Mac OS X hints [macosxhints.com].
Basically: KISS. Like, three commands for one concept? How would you like to open an application by clicking it, dragging it to another location, and then clicking it again?
Helpful? (Score:2)
I recommend giving each user a report 60 pages in length, and on pages 28, 29, 30 and 31 print in enormous letters:
R T F M
Then after they have digested this report, introduce them to the delights of man. :)
"IDNUTFM" (Score:1)
Then how do you respond to support requests containing
(I Did Not Understand The Intercourse-having Manual)?
Re:Helpful? (Score:2)
Well, T F M or rather, Ms, already exist, so perhaps it might be an idea to W T F M on how to R T F Ms? That way, there would be no problem asking people to R T F M because there wouldn't be a lack of understanding on how to do it in the first place.
That said, said people would have to R T F M on the topic of how to R T F M as to understand how they could R T F M in the first place. Doing that, IMHO, is the hard part.
Who are you writing your software for? (Score:3, Insightful)
This is a bit of a problem for open source, because most open source developers don't really think about end users (and if they do, think about them as "lusers"). And if they do, they tend to think the end users are as smart and experienced as they are, which is seldom true. So open source programs tend to get written for, well, programmers. If they work for other people too, that's viewed more as an added bonus that a requirement. I'm not mentioning this simply as a rant, but because you may be suffering from this yourself. And, more constructively, thinking about your program as a whole in this way may help you to improve it even more by making it useful to an even wider array of people.
My lecture (Score:2)
In addition to that, the Haifa GNU/Linux club has made many lectures about various subjects [haifux.org], all available online.
Dumbing down documentation? (Score:2, Insightful)
Creating documentation to meet the needs of your users is educating your users, it isn't dumbing anything down.