"Since 1999, I have been the proprietor of DNA Lounge, a world famous and award-winning all ages dance club and live music venue in San Francisco. I am also the developer of XScreenSaver, the standard screen saver collection shipped on most Linux and Unix systems running the X11 Window System. I released the first version in 1992. I ported it to MacOS X in 2006, to iOS in 2012 and to Android in 2015. On X11 systems, XScreenSaver is two things: it is both a large collection of screen savers; and it is also the framework for blanking and locking the screen. On MacOS systems, these screen savers work with the usual MacOS screen saving framework (X11 is not required). On iOS and Android devices, it is an application that lets you run each of the demos manually.
 

Where did you find the ideas for your screensavers?

Some of my screen savers originated as visualizations of some kind of mathematical principle, like, say, geodesics, moebius strips or fractals, or even just interfering sine waves, and I just mess around with it until the visualization looks interesting. Often choosing the proper algorithm for generating the color palette is key to making it look cool. 

More often, though, I tend to build simulations of real or hypothetical objects. For example, simulating a realistic looking lava lamp without doing a full simulation of its fluid dynamics. The trick for simulations like that tends to be to think of the right shortcut that will look realistic while in fact doing something much less complex than the real world physics. (This was far more important in years past, thanks to Moore's Law.)

And sometimes the savers come from "I wonder what it would look like if...", like, the way Splodesic ejects and reabsorbs the triangles comprising its surface. The idea I had in my head for that looked a bit different than how the implementation ended up behaving, but I was quite happy with what came out.

When I build simulations of objects, realistic looking or otherwise, I almost always do it generatively. I make very little use of hand-built 3D models, but instead generate almost everything from first principles, usually starting with cosine. That just feels more pure to me. 

I tend to put a lot of work into making the movements of objects and their components feel organic rather than mechanical and linear. I also try to make the behaviors be somewhat calm rather than twitchy. Just because you *can* achieve a frame rate that moves things around really fast doesn't mean that's going to be the best looking result. 

A few months ago I wrote in some detail about the process behind some recent savers, which I guess answers this question in a more specific way about a few of them.

Which challenges did you encounter when making the screensaver? Was the initial idea very different from the final software?

It varies widely. Sometimes they come out just like I envisioned, but often I will tweak things as I go, or accidentally stumble across some variation that looks better, that might be nothing like where I started. 

Since XScreenSaver is very old code, and It runs on many different platforms, the most challenging part is always just keeping it all running, and portable. Since some of the shared frameworks underlying my savers date back to 1991, there are quite a few compatibility layers inside there. 

One of the things I like best about writing screen savers is that once they are finished, they pretty much are finished. There the old joke, "The software isn't complete until it's last user is dead", but in the case of a screen saver, there's rarely a version 2. It does it's thing and mostly just keeps doing it.  Unlike most other software there tends not to be a lot of maintenance. 

Keeping the underlying infrastructure running tends to require ongoing maintenance, but the savers themselves tend to be stable. 

I wrote a very long article about what was involved in porting XScreenSaver to MacOS and iOS, which was certainly one of the bigger challenges.