Why don't some open source libraries provide binaries? I have noticed that some projects defer to third-parties who maintain current builds of the software, especially for Windows builds.

I ask because it seems like a barrier for adoption of a library. It's more work for the developer since he must set up his environment to build it. A developer also has to worry that he introduced bugs by building the library incorrectly.

EDIT: Some updates to address comments and answers. I've removed the examples since they're not central to the discussion. Also rephrased my question as "some open source libraries provide" rather than "open source libraries tend to provide"... didn't realize people would take offense to that.

  • 7
    "tend"? Two examples is a tendency? Do you have more data to support your claim? – S.Lott May 17 '11 at 18:20
  • 3
    Linux package managers are usually used to deploy binaries, so I don't understand that reference. – David Thornley May 17 '11 at 18:23
  • 7
    Because they are lazy pot-smoking college-educated hippies (the worst kind of hippies). – Job May 17 '11 at 18:23
  • 7
    Yeah, damn hippies writing software for free that half of the world uses, screw them! – Tamás Szelei May 17 '11 at 19:04
  • 3
    @CodeinChaos: I haven't built from source in years. Fedora, Mac OS and OpenSuSE must be weird exceptions to this "tendency". What OS are you using that's so poorly supported? I'd like to avoid it, if possible. – S.Lott May 17 '11 at 19:19

Because making windows binaries is a completely different job requiring a completely different knowledge base and tool set. People seem to have a difficult time grasping this about Linux developers, so let me turn it around.

  • You've used Windows for what seems like forever.
  • You only have Windows installed at home.
  • You've used Linux here and there at work, but only as a user, not administrating or developing for Linux.
  • You know gcc is the most commonly used compiler for Linux, but have never installed it on your own computer.
  • You mainly work on the software for yourself on Windows, but don't mind making bug fixes for Linux if someone else does the work to make it compatible and distribute binaries.
  • You don't want to pay for another OS and toolchain when someone else who already has is perfectly willing to make the builds.
  • 2
    In summary, some programmers do not have the knowledge, resources, or motivation to create binaries for other platforms. – M. Dudley May 17 '11 at 23:05

Cairo is a library, not an application. Postgres seems to have Windows binaries. Smaller projects often don't provide builds because they don't have the infrastructure/resources.

  • 4
    +1 especially "don't have the resources". Difficult to provide a tested Windows build if you don't have a license for Windows, don't have a Windows compiler (or time to experiment with cross compilers), etc. – Steve314 May 17 '11 at 18:56
  • 1
    @Steve314: Everyone has a Windows compiler - either the open source gcc, or the free Visual Studio Express. – gbjbaanb May 17 '11 at 18:59
  • 1
    A library can have binaries too, namely dlls. Often I don't have the compiler (installed) nor the dependencies to build the original library. So like getting binaries, even for libraries. – CodesInChaos May 17 '11 at 19:02
  • 4
    @CodeInChaos: Linux doesn't use .dll very often, so those binaries would be largely useless to some of us. Pure source would be better. – S.Lott May 17 '11 at 19:07
  • 9
    @gbjbaanb: Not everybody has a Windows installation, let alone a compiler. – David Thornley May 17 '11 at 19:31

It's part of the open-source philosophy of "if you want something done, grab a shovel." Naturally, it reduces the workload on developers if the users simply compile the program themselves. No need to worry about all those architectures, OS's, etc...

But, if you're making a consumer-level product (Firefox, Paint.NET, Audacity, Keepass, etc) and you care about acquiring users, you should always, always, always! include binaries. Probably only 2% of people who stumble on your website, and are interested in your product, are going to:

  • Download the appropriate SCM client
  • Check out a whole copy of the source tree
  • Download the IDE or compiler tools needed (easily several hundred MB for some projects)
  • Download and install all of the dependencies needed (and set environmental variables)
  • Run a fresh compile (easily a 10 minute process on some projects)
  • Deal with any errors or problems or arise (which in small projects probably aren't documented -- "oh yeah, the latest is actually in branch-rewrite, not trunk!")
  • Uninstall everything, or leave it all on your computer and re-compile for updates.

(Obviously on linux things are much saner, but most consumers still use Windows.)

It's far easier for newcomers to say "ooh, Windows version! Download. Run".

However, many open source projects are not consumer-level; they target programmers, who have a much higher tolerance for this sort of ordeal, and so binaries are DIY. In my experience, programmers can be just as lazy as users, though, so be warned. :)

  • These are exactly the types of issues that made me ask the question in the first place. – M. Dudley May 17 '11 at 22:17
  • 3
    Who would distribute a project that requires an IDE to build? And people don't distribute in SCMs usually. Its more like wget, tar xfz, ./configure, make, su -c 'make install'... – alternative May 17 '11 at 23:38
  • Fair points, mathepic. And more modern SCM hosts (like GitHub) will let you download a zipped copy of the latest version anyway. – Phil Cohen May 18 '11 at 4:20
  • @mathepic: Windows developers, that's who. – Stuart P. Bentley May 18 '11 at 17:12
  • @Stuart VS projects are just msbuild files. No IDE needed. – alternative May 18 '11 at 19:52

Creators of applications written in a Write Once Compile Anywhere environment (C, C++, etc) benefit from pushing the compilation step down to distributors (apt, rpm, yum, etc) that create and package binaries for popular architectures. This achieves a maximally portable application with less effort on the part of the creators and allows them to spend more time focusing on their core competency (developing the application, not compiling and hosting it for multiple architectures). Some WOCA application creators are willing to pay the extra cost in special cases like Windows because – well – no one else will, the users expect it, and they don't want to give up the market.

On the other hand, applications written in a Write Once Run Anywhere environment (Java) or for a specific target architecture (OS X applications, for instance) are able to provide a single binary and often do so since they only have to pay the compilation cost once.

Finally, their users are typically comfortable either building from source or using their OS package manager, so this model provides better usability as well. Users know where to get binaries (their package manager), have a consistent installation and package management lifecycle experience, and know where to acquire the source should they need it.

  • 2
    One problem with write-once-run-anywhere is that the virtual machine is a program in its own right, from the point of view of the O/S. For example, most Windows firewalls allow you to grant/deny access to networks on an app-by-app basis. But most of them can't tell one Java app from another - they grant/deny access to the JVM, but if you have one Java app that acts as an internet server (Azureus, perhaps) then the firewall will not block any unknown rogue Java application from acting as a server. If there's a Java-specific solution, I'm an example of a Java user who doesn't know about it. – Steve314 May 17 '11 at 22:21
  • 1
    @Steve I'm not disagreeing with you per se but I don't really see how the pros/cons of WOCA or WORA are relevant to this question. – Rein Henrichs May 17 '11 at 22:40
  • tangential, true, but in a question that's already a bit of a Linux vs. Windows etc religious war, maybe one of the lesser crimes. BTW - I did +1 your answer as useful. – Steve314 May 17 '11 at 22:54
  • Yay religious war! I'll get the tar, you get the feathers? – Rein Henrichs May 17 '11 at 23:25

Why would I want to chew up bandwidth providing you with a build (which can obviously be very large) rather than you building the source which I'm providing you with anyway? Not to mention that building a project on your own machine will always yield better results as it's compiled specifically for your platform..

  • 4
    +1 - but I doubt "always" (depends on what platform you're using), and those benefits can come at some cost to the user - needing a compiler, needing to know how to use it, needing to know how to build that specific project, needing to spend time investigating and reporting the wierd bugs that turn up only on your particular platform, etc. – Steve314 May 17 '11 at 18:54
  • 1
    @steve314: +1, all true points :) – Demian Brecht May 17 '11 at 18:57
  • 7
    A few binary files are usually not that big. And the time cost to the user is usually really large. Finding all dependencies and figuring out how to build that specific project takes quite a lot of time. Even if your user happens to be a programmer. If the user is no programmer he can pretty much forget about your product. And I think the performance argument is way overrated. Usually you don't need that last percent of performance, and if you do then you can still figure out how to build from source. – CodesInChaos May 17 '11 at 19:05
  • 1
    @codeinchaos: That's entirely relative to the project (size). A build could be encompass a single binary, or several hundreds of MBs (if not more) in binaries and non-compiled assets (think games). Of course, sometimes nailing down dependencies can be a bit of a pain, but that's up to the author of the package to either provide a list, or a build-time mechanism of downloading/building dependencies (FreeBSD's ports collection is great for that). Projects directed at non-programmers will almost always have a binary/installer list maintained somewhere. – Demian Brecht May 17 '11 at 19:11
  • Thing is, many open source projects aren't "products" in the usual sense. Since open source is about allowing contributions in various forms, having other people provide binaries that know how to do it and have the time to maintain them seems like a good idea. – phaylon May 17 '11 at 19:11

I can think of two reasons.

First, you have multiple operating systems running on multiple types of hardware; the number of binary targets you would have to build gets unmanagable. There are three versions of Windows still commonly in use (XP, Vista, 7) running on 32-bit or 64-bit hardware; that's 6 binary targets right there. The situation's worse on the Linux side, with a much larger variety of distros running on God knows what hardware (x86, PPC, MIPS, SPARC, PA-RISC, etc.). Are you going to build for every possible combination? Do you even have the equipment and/or software to do so? If there's someone out there still running (God help us) NT on a PII, are you going to build a binary for them?

Second, shipping source means that users can optimize the build for their particular environment; they can turn on whatever optimizations they need, or tweak the source itself if necessary.

  • so I guess the answer is to use something like Sourceforge's build servers. Checkin, let them build you lots of binaries. Such as en.opensuse.org/Build_Service – gbjbaanb May 17 '11 at 19:07
  • 1
    Since those programs usually don't use any special Vista/Win7 features and 32 bit programs run on 64 bit OSes you can almost always get away with a single 32 bit WinXP binary for all windows users. – CodesInChaos May 17 '11 at 19:08
  • @CodeInChaos - +1 - some projects provide both 32 bit and 64 bit binaries, but providing more variations than that is rare. A valid point, though. – Steve314 May 17 '11 at 21:46
  • @gbjbaanb - an answer, certainly, but probably not the answer. – Steve314 May 17 '11 at 22:14

Typically, the value of an open-source project, be it an application, system, module or library, is that it can be studied and/or modified as needed. Distributing the source is intrinsic to the publishing model.

Distributing a binary runs the risk that it has been modified in some fashion for nefarious purposes. Compiling the project from source attempts to mitigate that risk.

  • For applications >90% of the users will never even look at the source. And the risk of manipulation is something most downloaders of binaries are willing to take. They can't (and even if they could they'd be too lazy) to verify that a sourcecode doesn't contain malicious code. – CodesInChaos May 17 '11 at 19:12
  • 2
    True, but the OP asked why open-source projects aren't typically distributed as binaries, not "as a user, why do I have to compile all this stuff?" ;-) – Rob Raisch May 17 '11 at 19:17
  • But you're arguments are on why it's better for the user that he gets the source and not the binaries. – CodesInChaos May 17 '11 at 20:36
  • 1
    Funny, I don't see the word 'user' in either my answer or the original question. Perhaps I'm reading my own answer incorrectly? – Rob Raisch May 17 '11 at 20:39
  • 1
    Interesting that you seem hell-bent on misinterpreting my comments as I did not attempt to provide "a reason for not providing binaries." I simply provided an explanation for why open-source projects are typically distributed as source code. Thanks for playing but this is my last comment on this. – Rob Raisch May 17 '11 at 21:15

This can have several reasons. Many (if not most) open source projects start on Linux. So the initial project is done for this system and the packaging is done by team members.

Creating a Windows installer is extra work which requires knowledge that the Linux developers may not have. So if somebody from outside the core team takes on this work, he is often mentioned specially.

The same may be true for other systems like OS X or even specific Linux distributions. It all depends who has the knowledge and the time to do the extra work.

  • A windows installer is rarely requires. A zip file with the binaries is fine too. But of course you're right that many linux based devs won't care much about a windows version of their program. – CodesInChaos May 17 '11 at 19:09
  • 1
    A zip file can be a great handicap in the Windows world. 'I have downloaded this file. Now when I click it windows tells me its "unknown file format"' is a quite common problem in help forums. – thorsten müller May 17 '11 at 19:43
  • I've published all my stuff as .zip files. I think the only complaint I got in this context was by some guy who managed to copy the exe file to his desktop instead of creating a link. But in any case the difficulty of building from source is much higher than the difficulty of unzipping something. – CodesInChaos May 17 '11 at 19:53
  • 1
    Depends in part on your user base. If you publish a library that's only used by programmers you won't have problems with zip files. Zip is easy enough so every audience with basic knowledge gets it done. Though i have seen the zip question often enough... – thorsten müller May 17 '11 at 20:31
  • 1
    Keep in mind that in XP+, zip files are handled natively by the OS, and enough double clicking will open the file in an extracted folder. – Phil Cohen May 17 '11 at 21:59

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.