Open source practices even if you aren't using open source

At High Regard Software, we're trying to make it easier to "onboard" new developers for our startup, RideGrid. We are using some open source, notably pieces of Apache Commons. Even if you are not using any open source, there is a lot that can be learned from Open Source to make it easier to do development. The argument for this is straightforward: if the tool set works for collaborators around the world, who by the way generally are working for free, it has to be really low friction. If it's too hard to volunteer their time, they'll find something else to do. These tools are awesome and only getting better. We have been using SVN for a year, and we are just starting with Maven. I'm going to discuss these two tools and their benefits for you, based on our personal experience.

SVN, or subversion, is a version control system. It runs on Mac, Windows and Linux. There are different ways to configure the server, but the way we chose to do it is using SSH. All of our developers generate an RSA public/private key pair, and email us the public key. Once they can login successfully to the mac server using SSH, they can download the source code using SVN's ability to tunnel through SSH. Therefore we end up with a very easy and secure distributed version control system. We don't have to run a VPN into our servers, nor do we have to maintain a web server with access to the code.

Maven is a build infrastructure. It is a higher level tool than Ant, it does not replace Ant. To really appreciate it, you have to try it. Without Maven, we were getting third party libraries by downloading them and checking them into our repository. Because we are using NetBeans, we then were declaring libraries differently in every developer's workspace. Each developer had to declare the installation path to these JAR files, making the onboarding process tedious and error prone. We tried some hacks around this with limited success. With Maven, we simply declare these dependencies including version numbers, and the Maven gets them for the developer and installs in their workspace. But the larger benefit is that once we are converted over to Maven, we are IDE independent in a couple of dimensions. Prior to Maven, the only way to build and deploy an instance of our product was to fire up and properly configure NetBeans. Once our conversion is done, the entire product can be built, deployed and run from the command line; the only reason to fire up Netbeans is if you need to make a change or debug the product. Moreover, if we bring someone on who prefers Eclipse, they can load the projects into Eclipse. This is because both Eclipse and Netbeans have Maven plug-ins, meaning they can read and write the Maven configuration files. I haven't used Eclipse, but in Netbeans you simply create a project as a new Maven project; some of the operations (like the Library Manager) are no longer relevant when you do this, so there is a learning curve.

These two tools are helping reduce the startup time of new engineers. If your team is doing Java development, I'm sure they can help your team too.