Design consensus - the Apache way

The ways to lead the team

There are basically two extreme ways of leading the team of software engineers.

• Supervision. You control people in your team. You tell them what to do. You make a decisions for them, which you order to execute.
• Democracy. You are equal to the others engineers in your team. Your voice in design and architectural issues is equal to the voices of the others in the team.

As we well know, the bad team leads supervise their team. Good team leads serve their team and help them to perform.

The flaws of democracy

Let's face it - democracy is not always the best option.

Democracy in a team is good as long as all the team members are equally motivated, experienced and mature software professionals.

And what about new team members? They don't know the culture of your team yet. They need time to learn how people in the team works and what are the standards within in.

What about the responsibility? Your team works for somebody. Who should take the responsibility in the front of the business holder in the case of the failure? Who approves the critical decisions and takes responsibility for them?

The Apache way to lead the team

In Apache, all design decisions are based on the consensus between team members (committers). Voices of the project leaders (PMCs) are stronger than votes of regular committers.

However PMCs don't give the orders to the committers. They work with the committers on regular basis instead.  But in the case of design or architectural disagreement, PMCs are the ones who decide.

In order to become a committer, you need to work with the project team as a contributor. While being a one, you got no decision voice in the discussion. The is the time you learn the project and the way the Apache works.

I like to think of the good team as of the little Apache project. With a tech lead being the PMC, regular team members being the committers and team newcomers being the contributors.

Choose your weapon - wiki tools

So you feel bad about not using wiki, as you ought to? You wanna change it? You need a recommendation for the great wiki tools? I can recommend two of them.

• Google Sites - free wiki from Google. Perfect choice if you need to save some money and can keep your data in the cloud (people in corporations not always can).
• Confluence - great product from the great company named Atlassian. We use it at the Apache Camel. Can can host private instance of Confluence starting from 10$ per year (or pay Atlassian 10$ per month to use their cloud).

I've also worked with Alfresco and JSP Wiki, however I don't recommend them. Too complicated and unintuitive comparing to the Google Sites and Confluence.

I'm curious about your experiences with wiki tools. Any feedback will be highly appreciated. :)

Team hive mind

I'm always surprised how many developers don't got the habit of using company wiki. Wiki is a must-have for any development team that wants to be productive in the long run.

• If you don't share the details of your system's architecture on the wiki, how can you expect your team to understand the application they are working on?
• If you don't share the description of your development process, how can you expect your team to follow it?
• If you don't describe your coding practices and standards on shared wiki page, how can you expect your team to apply them?
• If you don't document the results of the research that took you a week, how can you expect your team not to loose another week on reinventing the wheel?
• If you don't share your knowledge and keep it in a single place, how can you even think about leaving the company for a week of a holiday?

Whenever somebody within your team asks you a project-related question, ask yourself why this information is not documented in the wiki in the first place.

Camel Extra available in Maven Central

I'm very happy to announce in the name of the Camel team that starting from today Camel Extra will be available to download from Maven central repository. The very first version of Camel Extra published to the Central is 2.10.0.

That basically means that starting from version 2.10.0 you don't need to include the ugly Camel Extra repository in your Maven POM configuration anymore. All you need to do is to specify the Maven dependency and it will be automagically downloaded from the Maven Central repository.

<dependency>
  <groupId>org.apache-extras.camel-extra</groupId>
  <artifactId>camel-hibernate</artifactId>
  <version>2.10.0</version>
</dependency>

This is the first step to keep Camel Extra in sync with its bigger brother. Many people complained about the quality of releases of the Camel Extra (if I got a dollar for every complaint about Hibernate integration I've heard...). Our goal is to make Camel Extra as reliable as "regular" Camel.

PS The major change we introduced in the 2.10.0 release is changing the Java package name from org.apachextras.camel to org.apacheextras.camel (please note the double "e"). We decided that releasing to Maven Central is a good moment for this kind of aggressive refactoring. Remember then to update Java package in your existing routing code.