Do you make a conscious effort to keep code compatible with older technologies when working on OSS?

Question

I've been the creator of a small handful of little OSS projects in the past, and although in no case did I necessarily intend to recruit anyone else to join me on the project, I still wondered whether it was "bad form" to use a more recent technology, for example leveraging features from a recent release of the framework/language used (where I didn't need to, but it just made things a bit quicker), thereby potentially making the project harder to work on for some developers.

As a trivial example, suppose I were to write some code for a .NET project that utilized the Enumerable.Range method (requires .NET 3.5); a developer working on Visual Studio 2005 with only .NET 2.0 installed would have to convert it to a for loop (or write his/her own Range-like method) just to get the code to compile. Granted, maybe most .NET developers are using at least version 3.5 by now; but that's just an example.

Anyway, is it good/bad etiquette to try to steer clear of newer features when working on projects that others might want to get involved in, where the version of a framework, IDE, or even the programming language itself, may vary among developers? Or is the prevailing attitude that it doesn't really matter? I'm particularly interested in hearing from those who have been in this scenario (working on an OSS project with others who work in different environments) ... OR who have enough experience to be able to tell me, "This scenario doesn't really happen."

Answer 1

I would say it depends on your audience. Consider emacs; it's target audience requires a wide range of compatibilities -- system, os, compiler and other sundry applications and apis. It's a large problem to advance the state of the art with Emacs; small changes have far-reaching consequences.

For any product, whether it's commercial or open source, you need to understand your target market (audience?). If your users are stuck on Framework 2.0, then yes you need to avoid newer language features, or give them a version of your product that can run in a degraded fashion.

Otherwise, why limit your product and yourself if it's not necessary?

Answer 2

Most OSS software is being used via distros. Because of the relatively slow rate of the trickle down process from new developer code to integration into distributions, if you code today using up to date APIs, chances are the API will be included in the distro before your current version is. Every open source project I have contributed to expects people who want to contribute to be willing to update to the latest version of all the libs and tools used by the project. If one of the libs being used comes out with an incompatible new version, it is normal for any incompatibilities to be reported as bugs, and for the project to migrate to compatibility with the newer version, with a longer term goal of dropping compatibility with the older version altogether.

With a situation like OSX, where the libraries are dependent on OS version and you cannot expect your userbase to upgrade they way they will with a open source OS, you deal with it like you would any other cross platform code. Code that has to work on multiple OS versions is cross platform, so you have configure script variables, #ifdef in the source, etc., all the standard cross platform techniques.

It sounds like you are talking about a situation where people are paying for development tools. This is a kind of unusual situation for open source, and one I have not dealt with, having only used free software development tools.