Thursday, September 18, 2008

How to open source an OSGi targeted tool?

I was working on a tool (with a funny name, or a ridiculous name if you will) for the diagnosis of stale references in the OSGi platform. It was part of my master thesis at Grenoble 1 university. The tool has been presented in an OSGi event in june, and in an academic conference in the beginning of this month. Among our “future plans” is to open source this tool. I am starting the PhD in the same university, and this tool will not be my main activity. I will have plenty of other things to do also. However we would like to continue evolving it.

But, I have several questions for all this process of releasing such a thing as open source. Maybe an inner self crisis!

1. Is this tool useful to anyone?

This tool is no rocket science and it does not cure problems, it only points a few of them.

My first thought is that the thing is useless, because I will always have the thought that what I’ve coded sucks and I could have done better…

But, if we do not make it available for the developer community it will surely be useless, since it would not be accessible to others. We never know if any a brave (and maybe a little insane) person would like to help evolving that.

2. How (and where) to do open source it?

Initially I may think to put it in sourceforge or google code. But my thesis advisor says it would be useless and without a good visibility for the target audience: developers of OSGi based applications. I agree. I’ve made available a small “useless” scripting console at google code, but the download count is insignificant, thus nobody is using it. We can imagine that a more specific project would fall into oblivion.

So, my thesis advisor, who is a committer in an Open Source OSGi implementation, has contacted its project leader. The guy said ok, but no more open source progress for our tool after that. I am not sure if : 1- he was just being polite and said ok; or 2- he is so busy that he can’t get into too much details on all mail that he receives. We also have not insisted since other stuff came up.

3. What if the code is not ready yet?

I am sure it is not ready. I feel like I’m leaving my house and while I'm not there people come in and see all the mess: dirt dishes, laundry, underwear in the floor. I would need to polish it. And after that, the project will no longer be “my house”, since it would belong to the community. Then the dirty laundry will be everyone's business.

But, that leads to another question: when would it be ready for that? I guess the polishing is just removing the really ugly hardcoded stuff, a few bad practices (did I just said that?). The GUI is complicated for the end user to understand it. It would definitely need some good work. I confess that in a 5 month project, with a bunch of articles to read, and also the master’s thesis to write I’ve neglected in some software engineering and also human interaction practices. If anybody has never done that before, cast the first stone.
Ah! Mavenization also. That's part of the polishing. For simplicity, I’ve used ant. Decent projects these days at least use maven for managing dependencies.

4. What if they find bugs in my code?

Normal. Just open an issue. I am far away from being a bug free coder and I guess 99% of the developers out there are not bug free either.

5. When to do the open sourcing?

Good question. I guess ASAP before I have even less time for polishing the code.

6. Volunteers for continuing the tool development?
I believe we have at least one: me :)

Well, these are basically my doubts that I share here in this post based on the little spark of dellusion that my master thesis result would be useful to someone.

Friday, September 5, 2008

Exclusive OSGi session at Euromicro SEAA

I was at the 34th Euromicro conference on Software Engineering and Advanced Applications (SEAA) to present an article about the tool that we have developed for detecting stale references in OSGi applications.
The conference had a session dedicated to OSGi in the Component-Based Software Engineering Track. Somehow it shows the industry/academia recognition of the important role that OSGi plays in the development of component-based appplications.

There were three articles presented in that session:
  • "Enhanced OSGi Bundle Updates to Prevent Runtime Exceptions"
    Premysl Brada
  • "Method for resource monitoring of OSGi-based software components"
    Tuukka Miettinen, Daniel Pakkala, Mika Hongisto
  • "Service Coroner: A Diagnostic Tool for locating OSGi Stale References"
    Kiev Gama, Didier Donsez
The other two presentations were pretty interesting. Each one of us showed little "hacks" for addressing some issues in the OSGi platform :)