EmForge Pre-History

In 2003, then I started my own software development company, one of the first question I had to solve - tools, need to be used for development. First of all I needed version control system and bug-tracking/task-management system. For both of them it is not a problem - there are a lot of tools available. Also, there are a lot of open-source solutions (I had no too much money to spend for expensive solutions).

First of all I started to use CVS as version control and Mantis as bug-tracking system. Both of them very nice and made a good job for me. After some moment we migrated to Subversion for version controlling... but... but it was still not everything I wanted.

I needed Integrated Solution: my dream is open task or bug description and be able to see the changes, done for this task or bug, or otherwise, look into commit comments, and be able easily see the bug-description, fixed by this commit... End this is only beginning! Since our company worked hard on BPM-Applications development for me it was clear - software development is a process, same process as in any other industry - and, if you want to be successful - this process should be described (at least) and automated as much as it is possible.

After looking into internet I found one solution (for that moment only one) acceptable for me: this is trac. (OK, I did not look into Rational Rose products or Star-Team and other same products - they are too expensive for me). And I like it very much, because:

• In many cases it easily implemented integration I needed: version control browser, issue-tracker, simple project planning and wiki-based documentation integration. In many cases it was exactly that I needed! And, using this page I want to say once again big THANK YOU to trac development team
• It was really easy to use;

We used (and still using) trac for about 2 years and I still like it. But, trac has two disadvantages for me:

• It has very simple and unfortunately hard-coded process for tickets processing. For example - ticket is simply closed by developer - there are no testing step to check by tester - is bug really fixed or not! Trac Team planning to add ability to change workflows for tickets, but for me it seems workflow engine should be placed into project initially... in other cases it will not be fully-flexible solution (something like this we can see in jTrac project)
• It is written in Python. Python is very nice language, but for me Java is much better. First of all because our company specialized in Java-development and I have Java-developers in staff. For me it was very hard to extend trac and add any additional functionality and I did not saw big reasons to invest into python education - there are no too many python-related projects available for me. Plus, Java has a lot of additional libraries, frameworks and ready solutions, that allows to reuse a lot of ready solutions and integrates with many other products)

After looking into internet I found, that a lot of staff already there: wiki-engine, workflow engine, subversion browser - everything we need is to place it together! And we started to do it.

EmForge development was started in the March 2006. First 4 month I spent for writing 'initial' concept version - just to place different staff together and integrate it. Unfortunately, I had no free resources to work on the project and most job had to do by myself in my free time. Also, since we had a lot of things to do - sometimes development stopped for month or more, because I had no time for it.

But, from January 2007 we found a way to assign more developers to the project and I really hope it will become stable and usable very soon!