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?

Comments

screenshots are absolutely necessary!

[Tumbleweed]

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

[Bruce Perens]

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

[Kreeblah]

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

[Carnage4Life]

Eric Raymond in his seminal work, The Cathedral and the Bazaar, 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();

[pjrc]

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 to , 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, 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).

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

[bcrowell]

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