Setting Up a Basic First Server

If you're a young startup, it won't be long before you need a server. The legendary first server … the one that will house all the initial code, run the first builds, and probably handle your email, website, wiki, bug tracker, and MP3 collection too. You'll probably want to get off the ground as quickly… and cheaply… as possible, and that means using open source software for most of your needs.

Here's a quick guide on what you should use (as of June, 2008).

Choose the same OS that you’re planning to deploy in your eventual production environment, or that you think most of your customers will run your software on (if you’re one of those old-fashioned ‘software is something you install’ sorts of firms.) Don’t have a clue? Pick whatever you know well or is popular at the moment. Generally, all Unix/Linux OSes are capable of running most any development environment that you’d want to throw at it, so just pick whatever everybody else is using.

My current favorites? FreeBSD and CentOS. FreeBSD is rock-solid stable, even under load (making it a great production OS), and is by far the most widely used and distributed BSD. Many big companies, including Yahoo, use it on their boxes. CentOS, which is derived from RedHat Enterprise Linux (a.k.a. ‘a Prominent North American Enterprise Linux Vendor’) is one of the most popular server OSes, and is also fairly stable and well supported. It isn’t quite as sexy as something like Ubuntu, but it just works. Well, most of the time, anyway.

There are all sorts of choices here, and it really depends on what you’re trying to do. For most web apps, especially for a startup, you’ll want something that’s fast and easy to work with. Something that contains nice built-in functions like in_array().

If you’re an engineer, and reading this, the choice will undoubtedly be very obvious for you. You’ll use Java/PHP/Ruby/whatever is hot at the moment. If you’re one of the business-ey types, you probably don’t have a clue - or even care that much. You shouldn’t… let your engineers decide.

Two words of advice here, though:

• Pick something with which you can iterate quickly. Building an app for a startup needn't (and shouldn't) be high engineering. You need to build it and get it out the door quickly. You’re not building air traffic control software, and lives are not on the line. You don't need to worry about Paragraph 3 in the Java license agreement, which says 'You acknowledge that Licensed Software is not designed or intended for use in the design, construction, operation or maintenance of any nuclear facility.' I can’t tell you how many startups I’ve seen who’ve overengineered their development efforts, and failed, or nearly failed, because of it.
• Be sure to standardize on a common development environment. The same version of PHP/Java/Ruby/etc., the same versions of the PEAR/Struts/ActiveRecord libraries, installed with the same options. It will save you HUGE amounts of time later on trying to debug all the annoying little bugs that crop up when those are different. For more on this, see the article on Choosing a Development Platform & Standards.

You are going to have a wiki, right? Where you put all the screen mockups, and the company directory, and the documents on your coding standards, and who knows what else?

Well, you’ve got plenty of options for Wiki software, but your absolute best bet is Trac. Written in Python, it’s an all-in-one wiki, project management, source code browsing ninja. While I don’t think I’d say its best-of-breed at anything, having all of your information integrated into one place is enormously helpful. It's designed for people building software, and it really works.

You’ve got plenty of options here too, including the vulnerable CVS, but your best bet is probably Subversion (SVN). Subversion is open source, free, and easy to use. For basic development, there isn’t much that is better.

If your app is going to be web based, you need Apache. Period. Actually, Litespeed seems to be gaining popularity recently, as a faster, more agile server than Apache 2.0, which is rather heavy. But Apache is still the granddaddy of them all, and is probably the place to start unless you have some specific reason to do otherwise.

Finally, when you set it all up, just do it! I strongly recommend installing all this stuff with the easy to use package managers, such as RPM on CentOS or the ports system on FreeBSD. Default installs are almost always fine. Don’t focus on rebuilding the kernel, or make custom builds of packages, or some such thing. Unless you have a specific reason to do one of those things, you’re just going to be spending time on goofy engineering that you don’t need to spend. Build your product first.