I'm excited to announce that iFountain has decided to go down the road not so less traveled and embrace the open source model. Being open has always been in our DNA, and we've agreed that embracing the open source model is the best manifestation of this objective.

As part of being open and transparent, I'll try to journal the road to open source for us. We'll try to get this done right. No doubt that it would not be difficult to post all the source code somewhere, stick on the GPL license, make a press release and declare the mission accomplished. But outcome of that alone would be no good for anyone. It takes more than declaring a license to turn closed source products into useful open source projects. Based on lessons learned from other projects, here is what we intend to do:

Open development infrastructure

It's clear that we need to implement an infrastructure to support open development where (most) developers are not in the same room. We need to make better use of the available tools to facilitate productive work and establish the methodology. Atlassian products JIRA and Confluence seem to be the defacto development/collaboration tools in many of the open source components we use, hence we intend to use them as well. We will also move from CVS to Subversion as the version control solution as it alleviates some of the problems we currently have.

I'm bummed that JiraStudio is not yet available (in closed beta) as I think it'll be a great solution for any distributed team. We'd love to use the JiraStudio instead of having to implement and integrate these tools ourselves. We'll keep and eye on it anyway. One can always hope

Solution architecture

As we transition our existing products into open source, we intend to rearchitect them, using a more loosely coupled component based approach that will facilitate plug-ins as much as possible. I think this is essential to make the code really “available” to people. Decoupling different components, will make it possible for others to use the components in their solution if they choose to. It should not be necessary for someone to understand the entire code base to develop additional functionality or modify/enhance parts of it.

Since our projects will inherently have significant integration requirements, plug-in structure should make it easier for others to create integration modules to serve their needs without having to master the entire solution.

Product design and messaging

Open source is an ecosystem. I think it is wise to take the existing landscape into account and address an area that ecosystem is in need of, rather than piling on an area where there are already existing open source solutions. I believe our solutions will fill a gap in IT management field and has very little, if any, overlap with existing projects and companies in the open source field. Hence, I hope that we will find significant synergies with other projects.

To emphasize this we will shed parts of the products where others do a better job (and use what's available instead) and focus on the parts we believe we're filling a gap. As can be imagined, this is not an easy feat, and we'll work on this heavily next couple of months. As always, any feedback will be more than welcome, to guide us to the right pastures

So what's the next? We will launch the development site (ifountain.org) with Jira and Subversion and release first version of “RapidCMDB”, an inherently fedarated CMDB solution for the enterprise by next week. Stay tuned to get more details on RapidCMDB ...