CamelCase

I am following the evolution of the Vert.x project since its inception and I was expecting to see some books coming about the subject sooner or later. First of all, some explanation on what's Vert.x:

"Vert.x is a lightweight, high performance application platform for the JVM that's designed for modern mobile, web, and enterprise applications."

The product is 100% open source, licensed under the business friendly Apache Software License 2.0 and well documented. The project's founder and main maintainer is Tim Fox, of HornetQ fame. »

Today Packt Publishing has published a little book I have written in the last few months together with Maurizio Pillitu.

The book is titled Apache Maven Starter and it's part of the Instant collection by Packt Publishing. Instant books are concise and focused technical guides, usually no more than 50 or 60 pages, providing the maximum amount of information in the quickest and most effective way.

Get to grips with a new technology, understand what it is and what it can do for you, and then get to work with the most important features and tasks.The book follows a starter approach for using Maven to create and build a new Java application or Web project from scratch.

I accepted the invite to write this book because, despite the huge amount of information already available on this subject, in form of other books and online material, when I started learning Maven I was searching for more concise information. The book actually doesn't aim to be a complete reference, but a place to start from and a collection of pointers to additional information. So, it is the book I wished I could read years ago.

Maven ultimately allows for the automation of the build lifecycle and independence from any IDE. You must always be able to build and test any Java project from the command line, using your favorite editor for coding. It is important to control exactly what libraries get distributed with Java projects and to have a standard project template and build process. 

Instant Apache Maven Starter will concentrate the most useful information into one single, very compact source. 

What you will learn from this book

While reading an article on ZDNet titled "Open source: Its true cost and where it's going awry by Monty Widenius" I think I have realized why most people, even those tightly involved in the open-source ecosystem, are often misunderstanding its business model. In a sentence:

The open source model is about creating collaborations, not building products.

Advocating open source software since the early 90s, from my point of view an open-source business model related to products can be misleading.

"The problem is — I saw this very clearly with MariaDB — I created a company where I took the original people who were creating the product, [but] I couldn't get anybody to fund us," Widenius said.

Before being bought by Sun for an astronomical amount of money (1 billion $), MySQL was profitable but in the range of few tens millions per year. You don't meet every day somebody putting billions on the table...

My question is: what would force a company to pay for a product if they can have it for free? I guess RedHat owners asked themselves the same questions when they practically closed the RHEL product line source code, moving the community toward the Fedora project. And now RedHat is making an huge amount of money from a product that is, by all means, the (almost) closed version of an open source effort.

So, it is really hard to build open source products, like RedHat or Alfresco, for example, because, despite all the efforts to justify a dual licensing model, you cab grasp only a very small percentage of users available to pay for a commercial edition of any open-source software. Stressing the fact that going into production requires paid support can be helpful, but it's very hard to demonstrate where the break-even is. Somebody coud argue: is that product so buggy that I need to pay a lot of money for support? Very few companies have been successful in this.

Instead of selling standalone products, I see an easier path in building solutions and services on top of an open source ecosystem: companies and their developers collaborate in growing a set of tools, frameworks, libraries with an open source development model and communities. This allows to dramatically decrease R&D costs, sharing the benefits. Today I could build a whole enterprise platform with open source software only, from the operating system to middleware and client applications, probably with better quality than a closed counterpart. But, as Widenius seems is learning the hard way, building an open source product and having paying customers is a different story: not impossible, of course, but very hard.

Widenius again: "Open source is successful for OpenStack where you have a consortium of companies that are all putting money into developing it."

Exactly what I mean: join to develop the common parts, share the costs and then compete in selling some unique services. But a stand-alone, open source product, created and supported by a single company, is a different story.

Github is the tool I use daily to manage my public software projects, I love it. But sometimes I have to quickly and temporarily share private projects with colleagues or maybe even in a mixed environment, with customers and consultants from other companies. When there is no time / money to buy private remote repos from Github or even install a local Git repo on some server,  and for privacy constraints it is not possibile to publish the code on a public Github repo, then Dropbox comes to the rescue.

In this example I'm working on a simple Web application in Flask, which is a cool Python micro-framework. I created a "flask_sample" folder which contains the code I want to version with Git and share with other colleagues.

I promised it will take less than 5 minutes, so let's start.

Move to your Dropbox folder (in my case it's in /Users/mturatti/Dropbox/) and create a folder to host all your remote git repositories:

$ cd /Users/mturatti/Dropbox/
$ mkdir git

Then create here the folder to host this remote repository:

$ cd git
$ mkdir flask_sample.git
$ cd flask_sample.git

It's time to create a bare Git repository:

$ git init --bare

You'll see it creates a structure similar to the following:

mturatti:~/Dropbox/git/flask_sample.git$ ls -l
total 24
-rw-r--r--   1 mturatti  staff   23  9 Nov 18:38 HEAD
-rw-r--r--   1 mturatti  staff  112  9 Nov 18:38 config
-rw-r--r--   1 mturatti  staff   73  9 Nov 18:38 description
drwxr-xr-x  10 mturatti  staff  340  9 Nov 18:38 hooks
drwxr-xr-x   3 mturatti  staff  102  9 Nov 18:38 info
drwxr-xr-x  11 mturatti  staff  374  9 Nov 19:09 objects
drwxr-xr-x   4 mturatti  staff  136  9 Nov 18:38 refs

Now you have in place a git structure which can act as a shareable remote repository, even if in practice it's local to your hard disk. Being a Dropbox folder will do the magic in terms of backups, sharing and synchronization.

Initialize Git in your software project as usual (in my case the local project stays in /Users/mturatti/src/flask_sample)

$ git init

This creates the usual hidden .git folder.
The last configuration step is to add locally the previously created remote Git repository:

$ git remote add origin file:///Users/mturatti/Dropbox/git/flask_sample.git

Note we are using the file:// protocol for the remote Git repository here.
If you check the content of .git/config file you'll see the new origin (in bold below):

mturatti:~/src/flask_sample$ cat .git/config 

[core]
repositoryformatversion = 0
filemode = true
bare = false
logallrefupdates = true
ignorecase = true
precomposeunicode = false
[remote "origin"]
url = file:///Users/mturatti/Dropbox/git/flask_sample.git
fetch = +refs/heads/*:refs/remotes/origin/*

At this point you can start the usual Git lifecycle. For example, after you have added and committed all your files locally, you can "push to origin", which will push your code to your remote Git repository saved on Dropbox:

$ git push origin master

The last step will be to share the Dropbox folder with your colleagues, so that they can also add this as a remote repository and start cloning / pulling / pushing from this origin.