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.
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.
2 comments:
This sounds familiar to me. :-)
Some advice/observations that I can offer.
To open source your project you must first clear any intellectual property (IP) hurdles you may have at your university. You must make sure that you have the right to open source it, which means you must check with your university/group's administration.
If you want to contribute to a specific open source project, e.g., Apache Felix, it is not as simple as someone just saying "ok". The contribution needs to be presented to the community for discussion and eventually voted on for inclusion. The issue here is that the community doesn't want to have code dumped on it that has no future, so if the community doesn't have enough interest to accept responsibility for the code, then it might not be accepted.
If it is accepted then you will also have to look into the specific IP requirements for that community, e.g., Apache needs contributor agreements signed. Further, you also have to be concerned about IP issues from any transitive dependencies, since Apache projects do not like to have dependencies on any arbitrary license. These issues will get uncovered during the IP clearance process, but it would be nice to know about any that exist in advance.
Lastly, you have to be persistent. Open source can be a lonely pursuit sometimes, especially when you are pushing an idea that hasn't yet caught on. If you believe in your idea, then keep doing it. But if you think it isn't good, then there is no reason to be pushing it on anyone else. However, lack of popularity or visibility is not the same as being a bad idea. The trick is knowing the difference. :-)
Hello Richard,
I’m surprised and glad for your advices :)
Concerning the university rights stuff I would think that there is no problem at all.
My main doubt about open sourcing it is if people would be interested in using the tool and how to attract other developers to help improving it. There is a lot to work on that, but interest of other would motivate the addition of new features/improvements.
Part of me thinks it is worth the effort. But the two “mes” (the little angel and the devil) inside my head have different opinions: Although the diagnosis is limited for the moment, I think the approach is interesting and useful especially in legacy code that is being “OSGized”. The other says that this is useless and that I should leave that and move on.
Apart from that mental conflict there are some project issues that I see:
-We weave the bytecode of OSGi implementations. Maybe this is a little invasive. I don’t know how you guys from the bundle 0 side see this trick.
-We depend on AspectJ for weaving. This complicated the classloading/classpath, and the nasty solution was to embed it in the same jar of the weaved OSGi. Not sure about the licensing and legality of this procedure.
-The diagnosis that we perform could be part of a bigger tooling set targeting OSGi instrumentation, but I don’t know if there is any. Maybe it could be a nice effort to gather such stuff together. I think that this would be much more interesting to users.
Thanks a lot!!
Post a Comment