tag:blogger.com,1999:blog-7414681341906437667.post770746498061948421..comments2015-05-15T02:07:46.684-07:00Comments on Just an ordinary Java blog: How to open source an OSGi targeted tool?kiev gamahttp://www.blogger.com/profile/17229100175885523440noreply@blogger.comBlogger2125tag:blogger.com,1999:blog-7414681341906437667.post-53087163344972299222008-09-19T01:31:00.000-07:002008-09-19T01:31:00.000-07:00Hello Richard,I’m surprised and glad for your advi...Hello Richard,<BR/><BR/>I’m surprised and glad for your advices :)<BR/><BR/>Concerning the university rights stuff I would think that there is no problem at all.<BR/><BR/>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.<BR/><BR/>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.<BR/><BR/>Apart from that mental conflict there are some project issues that I see: <BR/>-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.<BR/>-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.<BR/>-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.<BR/><BR/>Thanks a lot!!kiev gamahttps://www.blogger.com/profile/17229100175885523440noreply@blogger.comtag:blogger.com,1999:blog-7414681341906437667.post-3049367488819422482008-09-18T13:15:00.000-07:002008-09-18T13:15:00.000-07:00This sounds familiar to me. :-)Some advice/observa...This sounds familiar to me. :-)<BR/><BR/>Some advice/observations that I can offer.<BR/><BR/>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.<BR/><BR/>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.<BR/><BR/>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.<BR/><BR/>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. :-)Unknownhttps://www.blogger.com/profile/05901039297072423888noreply@blogger.com