Why Are Binaries And Screenshots Good Things?

QuantumG asks: "I recently got into an argument with an open source project leader over wether or not releasing precompiled binaries is a good thing or not. He was adament that if potential programmers had to download the pre-alpha source code they would be more likely to take up an active part in programming than if they could just grab a binary. I thought it was important to make it as easy as possible to show the current state of the project to new recruits so they could see what has been done, what needs to be done and what could use work. I feel the same way about screenshots. What does Slashdot think?" Binaries are definitely important. Remember, programmers aren't the only ones who would like to look at your code and see what you are doing, and it's not right to expect them to compile code that may not be easy to compile. Of course, there is a (debatable) point in the software lifecycle where the software is deemed "mature" enough for binaries. What do you all think about this issue?

Binaries for which system?

There seems to be an unspoken assumption in this thread that open source programs are intended to run only on 386-compatible Linux boxes, so that one set of binaries will suffice for all users. Releasing binaries only for that standard vanilla platform is a nice way of reminding users of other systems that they are second class, and also this kind of development is a nice way to make sure that your software is less portable than it otherwise should be.

For this reason I think it's better in the early days of a project to release source only. Binaries can wait until the software's in shape for use by non-programmers.

Why is it a big deal?

Does it really cause a huge havoc to release the binaries? Lets see, it's not that much more work - it's easy and doesn't require any additional effort than releasing a properly setup tarball.

The benefits of this, if I think the idea behind the project is cool and it's been in an active development state and I download the source tarball and try to compile it and it fails I will probably desert the project. However if I look at something that actually runs to see if the time they've spent has been good and that it looks pretty solid and has a good start, then I'll wrestle with getting their CVS/alpha/pre package to compile and build on my machine.

Whoever thinks binaries are a bad thing, with no good merits I feel sorry for them. However, any application that I use on a regular basis will be compiled from source and optimized for my platform if possible.

Re:binaries are the way to go

I for one just want the best OS for me, I don't care who else uses it... If to attain that we need to get the masses using it, so be it. But it's not a goal in itself.

That's a bit short-sighted and simplistic in my (less than humble) opinion. Linux users want popular games, software, DVDs, ad nauseam. Much of this won't happen until the OS hits "critical mass", or, until it reaches a point where the companies making these things see that it is a OS that they can make money from.

I desperately would like to see Linux and/or BSD become more user friendly and more used, so that I can ditch Windows solutions completely and use one or both exclusively.

Developers aren't the only needed participants

Developers aren't the only needed participants in Open Source development. Taking the attitude that only developers can contribute is very bad. The guy that certainly is not a engineer, but a mere coder (can hammer and saw but cannot build a house).

A non-developer that has access to a binary can:

a) Write documentation, tutorials, etc.

b) Excercise the application in ways that a user would, thus finding bugs that a developer would not.

c) Ensure that the program does what it is supposed to. If there are reqs or specs, then they can be tested. If not at least it can be tested against the "web page".

d) Get excited about the project and tell all of his developer friends.

Milestones are A Good Thing

There's plenty of apps out there that are in a constant state of development, and yet are usable because of milestone builds. Two good examples are Mozilla and Evolution - both (IMHO) excellent apps which, thanks to having easily installable binaries (both are apt-able) I can easily use in a production environment at work.

However, it's important to note that source is avaliable for both. Before i had a full-time job (and less than 512Mb of RAM :) ) I used to compile moz milestones myself, so I could ditch the mail/news component and other cruft which i didn't use. Milestone binaries are A Good Thing (TM), but they need to come with source to be really worthwhile.

Alpha Binaries - No, Beta and Releases, Yes

I've found that releasing binaries are essential
to making an open source project successful.

That said, I usually don't release binaries for
alpha releases or early betas that are likely to
contain bugs - better to let the more experienced
hackers (in the true sense of the word) run into
any problems and report (or even better - fix!)
them than spend days with a newbie only to find
that they haven't found a problem but are using
the thing wrong.

Once you know the code is stable enough for
mere mortals to use, get the binaries out! A lot
of inexperienced users (and experienced ones,
too! :) don't want the hassle of compiling the
software themselves if they don't have to.

This is a C-centric question

This assumes you are writing code with gcc. If you are using one of the other myriad of compiled languages available, everything from Lisp to OCaml to Pascal to Eiffel, then you most certainly want to distribute binaries. Not everyone has the latest versions of those compilers sitting around. There are sound software engineering reasons to not use C and C++ for everything.

Re:Lack of binaries hurt.

I agree with one thing, here, and that's that I like to put binaries where I think they should go (too many people think their stuff actually belongs in /usr/bin!).

But the big problem I see with asking people to compile programs - and this goes for binaries, too, since they are typically GPL'ed and you need to have the source code available, is the dependencies.

In other words, who here has compiled enlightenment with all the options? How many packages from other people do you need? How many image libraries and crap do you need? It gets ridiculous, because often those libraries have depencies of their own. I like keeping things simple, myself, so I just don't do it - enlightenment is a good example of something that I might want to try - but not enough to spend hours online downloading depencies and then wading through it all to make sure everything gets compiled in the right order. So I tried what came off my linux distribution and thought it was kind of bloated for my liking - saved myself a LOT of time.

----------

Mixed ideas...

I like the idea of releasing binaries AND source. Some programs, such as gnome or X, i just dont have the patience to compile from scratch, so RPM's are convenient. Other things, such as GAIM, i update from CVS daily. As for screenshots, i like to use those when first downloading a program to see if the program is jsut a gui or is actually filled with a few features. Sometimes they are misleading, but they are good for hooking new users. It's all personal preference.

Free Windows compilers

Distribution of binaries is of the utmost importance for platforms like Windows, where a compiler does not come with the operating system, and the compilers that are readily available are often non-free.

So what if MinGW [mingw.org] or Cygwin [redhat.com] doesn't come with the system? They're both easy to download and install, and they're both GPL'd free software (based on GCC and other GNU stuff). Or, you can use the (non-free but free beer) LCC [virginia.edu] compiler. However, Mac OS 9 systems (that can't run OS X because don't have a G3 mobo and 128 MB of RAM), on the other hand, don't even have a command line; good luck getting GNU anything to work.

Tetris on drugs, NES music, and GNOME vs. KDE Bingo [pineight.com].

Re:Enough with goatsex.

echo 127.0.0.1 goatse.cx >> /etc/hosts

Problem solved.

Re:Why is it a big deal?

The one drawback, I think, is that binaries may generate a lot of unhelpful bug reports. (See this one [kde.org], for example.)

Binaries are susceptible to all sorts of little inconsistencies between installations that source can pave over. The result is a flood of "I get this this error on Storm Linux with XFree86 and GTK whatever." mails. Also, releasing source-only creates a small barrier to entry that restricts distribution to people who understand what "pre-alpha" means.

Screenshots, on the other hand, seem like they're always a good thing.

Binaries a MUST!!!

Let us not lose sight of the fact that we are talking about the creation of Software, who's ultimate goal is to be usefull. Some people do not wish to program, but are willing to supply a list of bugs that have been found. This is an important part of the development process, even in Alpha stages. It is said that a bug caught in the earlier stages of development and fixed in an hour, may take weeks to fix if found at a later stage. So yes, allow the binaries to be downloaded. You may lose a programmer or two, but, in the long run you are allowing a greater range of people to contribute through commentary and bug reports. Falkenberg

Packaging

The truth is that it is in the packaging. Any time that something becomes difficult to install, many people will drop it. For example, I was just trying to get Bochs [bochs.com] up and running last night. When I tried to compile the code, the compile would fail every time. I went in and found that some of the header files had a definition of NULL that the compiler didn't like. So I changed it and tried again. Now it was something else. So I found the binary for my system and tried that. Of course, libstdc++ just said "symbol __ti9exception not found". Finally, I just downloaded a BSD ports package which installed and ran without issue, even though it was source.

The reason why binaries are more popular is that they are generally easier to package. The dependancies of source is such that you must have the right compiler, the right linker, the right header files, (sometimes) the right platform, etc. The dependencies with binaries are such that you must have the right platform, and the right libraries. The libraries can often be included or automatically installed via a packaging system. This makes binaries far easier to get running.

So what's the moral of the story? Package your binaries to meet the needs of the target audience, and package your source to meet the needs of its audience. Between these two, your customers (paying or not) will be far more pleased.

Re:binaries are the way to go

Remember, we want linux as a desktop for the masses, right?
We do? I for one just want the best OS for me, I don't care who else uses it... If to attain that we need to get the masses using it, so be it. But it's not a goal in itself.

Both

Being into graphics, I really need to see screenshots before downloading some of these graphics applications - but that's not the only thing I consider, of course.

I also download both the binaries and the source (nice to have a cable modem) depending on the program. As has been mentioned, I'm not interested in compiling a spreadsheet or word processor. Trying to force me to do something a developer should be doing isn't going to make me want to help.

Everybody has their area of interest, and in those areas I'll look at the source, and maybe change and compile it, but not for the other things. It's ridiculous to feel everyone should have to compile a program. Don't we want to encourage use of Open Source across demographics of users?

In any event, not giving binaries will open the doors for new websites, maybe ad sponsored, that let you download the binaries anyway.
----------

Lack of binaries hurt.

I believe that the lack of binaries being released for linux is one of the major drawbacks that is keeping it from becoming a major OS competitor. Many of my tech-friendly friends have installed linux, but lacked the programming skills to install a lot of the software they wanted. The difficulty of compiling software has actually made some of my friends reject linux as an operating system. I do believe that source code is important, but for linux to become a viable operating system, binaries will have to be released more often, or at least an easier way to install software.

Enough with goatsex.

This is "Offtopic". Moderaters, lay off.

Is anybody else on Slashdot tired of these childish goatsex links? It really is a distraction, even after I set my threads to +1 and above (occasionally I want to dip down to see what AC's say, and most of what I read are these links).

Two suggestions: AC's who post this, get a new hobby. Even the juvenile posts about grits were better than this (no image to fill up my workscreen).

Second, Rob, Hemos, whoever's in charge of these decisions: ban the dumb link. It's one thing if it's "freedom of expression". It's another thing to see the same damn picture over and over and over again. If you cry "first amendment right", let me just say we heard you the first time, poster. Now grow up.

screenshots are absolutely necessary!

If I can see a screenshot, I can get an immediate idea of how the interface of the program works. As a UI designer/developer, I'm SUPERPICKY about interfaces on the apps I use.

There are many FTP clients, for instance, and most of them will do everything most people expect them to be able to do. The difference for most of them is in the _interface_.

Downloading a screenshot lets you know right away whether this this looks like the kind of interface you'll be happy with, without the trouble of downloading a full binary and installing it, much less the time and trouble of downloading source to an app, compiling it, installing it, etc. If all you want is an idea of the interface concepts being used, a screenshot is the ONLY sane thing to use.

Mind you, that's about ALL it'll tell you - but the interface is all-important. It doesn't matter what an app is capable of if you can't figure out how to use use it. What kind of life is it you lead if you're willing to put up with annoyingly-designed software all the time?

It could also be used by savvy app developers to find out what people think of their app interface. If you have the binary or source available on your site, and a screenshot or two, take note of how many people check out the screenshot versus how many download the app. Take a look at the ratio and get a clue about your interface. There's a REASON KDE & Gnome exist.

Provide early binaries, but maybe not Alpha

Provide early binaries, as soon as you are ready for non-programmers to help you find bugs. Compile them with -g and make sure they clear the core-dump-size limit when they start execution, so that you can get a valid core dump.

People who want source will click for source. Certainly I've debugged many a Debian program starting only with a binary, and then downloading the Debian source package.

Thanks

Bruce

Precompiled binaries

OK. Say the Linux distributions didn't want to release procompiled binaries. Say they wanted to make their users truly understand how the various distros work. How many of you would still have tried Linux if you had to compile all the binaries yourselves?

Releasing binaries is a good idea for many reasons

Eric Raymond in his seminal work, The Cathedral and the Bazaar [tuxedo.org], stated that one of the ways to create a successful Open Source project is to release something that developers can use and find useful. As a developer it is easy for me to run a program and decide if I think it has potential or not, on the other hand it's a pain for me to look at 10 - 100 source files trying to figure it if the design is good and why I can't compile it.

Another good thing about releasing binaries is that it gives the developers more incentive to fix bugs and create milestones than if they just released source and makefiles at random because it means they have to make the software run as smoothly as possible and tackle usability/configuration problems early.

In my opinion screenshots are not as useful but still serve a purpose such as enticing people who are just browsing through projects at Sourceforge to take a closer look at your project.

Grabel's Law

if (dist==SOURCE_ONLY) comile_without_hitch();

I've been programming in C and using unix systems for over 10 years, and linux since kernel rev 0.99pl14 (a few months before 1.0). The days of POSIX and linux are much better than the bad-old-days, when you'd often times have to edit the source and change <strings.h> to <string.h>, and dozens of other minor (and many not-so-minor) tweaks that I'm thankful are only a distant memory. When I was a grad student at OSU [orst.edu], I'd spend a lot of late nights trying to get code (usually written at Berkley) for SunOS to compile on HP/UX (HP has a major presence in Corvallis, which is otherwise a college town), 'cause the free code from Berkley tended to work a lot better than the bloated crap from a major EDA vendor who's located about 70 miles to the north (that was their 8.0 release, which basically didn't work at all, it had so many bugs). [mentorgraphics.com]

Today's world is so much nicer... "./configure", "make", "make install" (well, I'm a bit wary of that last part, as it usually needs root). When this very nice process doesn't work, usually the configure script tells you when you need to do. Pretty cool.

Still, there are source-only distributions that fail to build. Now I can understand this if it's from an up-to-the-minute CVS, but from a tarball on a web page or ftp server, that's not so cool. As a programmer, the software needs to be something pretty special for me to go dig in and fix the build process. It's just not fun work (particularily for a large project), and unless you've got quite a bit of experience, it can be nearly impossible.

So if you're an open/free source author and you don't offer binaries, make sure the code builds on the systems you're hoping your users have.

Early, not late

I'm not sure I even buy the argument that a project should reach a certain point of maturity before one releases the binaries.

Several reasons:

1. It seems to be a Law of Nature that open-source projects attract the most help when they need it the least -- i.e. once they're mature. At the beginning, it makes sense to do everything you can to encourage people to participate, including enticing them with binaries.
2. Early on is when people are most likely to encounter problems compiling through no fault of their own. Come on, how many software projects are designed to be perfectly platform- and compiler-independent from the ground up?
3. If you're starting out with a one-person project, you have the luxury of waiting as long as you want before you even open-source the code. Suppose you write an initial version that is full of security holes, but that does demonstrate some key functionality. You might want to release a binary, then spend a month fixing the security, then open-source the project.

I think it depends a lot on the project. My only open-source project [lightandmatter.com] is an applet that shows the planets in the night sky. I've gotten lots of help from strangers with translating it into various languages, and that's actually the full extent of other people's involvement since I open-sourced it. I don't think any of those people would have known or cared about the project if it hadn't already been an applet that was sitting there on my web page and was actually useful for something.