I have a lot of respect for the way AOK systems approaches the whole subject of IT so reading Tobias's blog was simply a must . It turned out, that his suggestion for open source was something I had looked at earlier this year and so it was only a matter of finding time to respond. Intro... First off. I love Open Source. I got involved through a project to enhance the capabilities of my television receiver at home (it has a C API) and for purely selfish reasons I downloaded someones code, added my personal improvements and eventually these made it to the open source version available to everyone. That's great for me because there's no competitive advantage in my receiver working better than my neighbours (but there is an advantage for the manufacturer competing with other vendors) and my improvements are future-proofed because they made their way into the code supported by a complete community. And to be honest the risk is minimal (worst case - I lose TV reception for an instant and have to reboot) but this has never happened. And were there dark evil parts of the code that could damage my receiver? Well I checked the source code and the forums and felt confident enough to live with the risk, after all I'd compiled it myself. Status Quo... I hope you won't be disappointed to learn up-front that what applies to a TV receiver does not necessarily apply to Business Software and I learned that open source is not an option at SAP. The blob of code (AKA SONiC) created by Lars Rueter together with Thilo Brandt will not be released as open source. Why not open source... There are good reasons against this. I won't go into detail. I won't even summarize because even doing this would be misleading. I'll just say that I have discussed extensively with learned colleagues in other areas (e.g. technical, legal..) whose opinion has always been worth respecting and whose respective areas are such that I just don't have the background, experience or basic knowledge to even begin communicating the arguments down the line (Chinese whispers). That's a fact - move on. Pragmatic approach... Part of the goal of any open source is to serve as example code rather than out-of-the-box solutions. And that is how Lars and Thilo created the code in the first place. And that is why you'll find it in the example downloads section in the first place. Will it work out-of-the-box if you deploy it without checking? That's a risk no sane IT manager would take. But it's existence sure is useful and saves a lot of time starting from scratch. The only hurdle left was to make sure that it really can be handled as software that can be iteratively improved by a community. That turned out to be trivial and solved by SDN itself. There's a subscribe (watch) mechanism that you can use to learn about updates. So all I had to do was create a thread that is subscribable to promote innovation ("let's add this...") and make this public. UWL - SAP Office Notifications Connector (SONiC) Even though there is an download-example forum I chose to make this subscribe-post public in the forum related to the business aspect of the code (NetWeaver Business Task and Process Management forum - BPM) because I hope that is where most of the ideas for improvement will be generated. What won't work... There's still effort required on our side to add suggested improvements to the code. This means that the process of deciding what is included is and what isn't is not democratic or as fast as it could be with more open access. At the same time, it is still simply example code so we cannot offer an SAP stamp on the code to say this has gone through a complete QA process to make sure that it is not dangerous or unstable. It is simply example code. Nevertheless we hope that this is a useful step for customers and partners alike and one which will survive the test of time. The code in this case was not ABAP but Java but I don't see a problem using this approach with ABAP either. The approach is not innovative. It's pragmatic. But maybe that's the best approach to take. Epilogue Last week Google released their new search engine for digging up source code. http://google.com/codesearch You can specify the language (e.g. Java) as well as other attributes, such as what license is involved. It would be nice to see ABAP added to the language list (there are already other proprietary languages tagged already) but for the moment I hope you'll agree that what I have described here is a reasonable approach.
