Apache Maven Starter - my first, little book

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

• Download, install, and configure Apache Maven with the minimum fuss
• Make your own Java project templates and reuse them
• Deploy to Tomcat or run an embedded Tomcat with Maven
• Perform unit and integration testing with Maven and JUnit
• Manage dependencies and project coordinates, adopting best practices
• Create and manage multi-modules projects
• Use Maven from your favorite IDE: Netbeans, Eclipse, or IDEA

I want to especially thank Maurizio Pillitu and the Packt Publishing editorial team, it has been great to work together guys!

The book is already available on Amazon, Packt and Safari Online.

Open source products: the big misunderstanding

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.