Skip to Content
Author's profile photo DJ Adams

SAP and Open Source: an analysis and letter to SAP and Shai

Well this has certainly been an interesting few days in the intersecting worlds of SAP and Open Source. There’s been a lot of comment and discussion already, but having listened to the whole Churchill Club interview and conversation audio (both available at ZDNet) on an early morning drive down to London yesterday, I would like to make some observations.

Rather than focus on some of the worrying remarks that others have already commented upon (intellectual property socialism, innovation, and so on), I’d like to take one part that deals with source code, as that’s been my bread and butter for the last 18 years of working with SAP software.

Shai is understandably keen to see that his comments are not misrepresented – see I LOVE Open Source—Really!, so I took the time to transcribe exactly what he said in the interview. What follows is from between 35:40 and 37:00 of the interview’s MP3 file, when he responds to a rather general question about Open Source. The response deserves some analysis.

So we analyse Open Source a lot, in the, you know. Most people don’t know it about SAP but we are one of the first Open Source and one of the worst hit Open Source company [sic] in the world.

Worst hit? What does that mean? It’s difficult to tell, because it doesn’t really make sense, so I can only assume it’s either general FUD (equating Open Source to an undefined but undesirable situation) or a taste of what’s to come later on in his response. I suspect the latter.

That said, let’s give SAP its dues; I’ve long carried the flag for SAP for making (most of) the source code to R/2 and R/3 available – see my comment to Visiting SAP NetWeaver Development Nerve Center for example. But don’t get out the champagne yet …

We shipped all of our applications to all of our customers ‘source open’. So the processes that you get from SAP, you get the source of the processes.

To a large extent, that’s true. Of course, it depends how you define ‘application’. Source code for the business applications, in the form of ABAP (and assembler in R/2 as well) is available. But source code to to the kernel, and certain parts of the Basis, err sorry ‘Web Application Server’, system is not.

And you’re allowed to modify them, which causes the worst disaster in our ecosystem because every single one of our customers decided that “that’s a great idea, let’s go modify the source”. And when they get the next version, they go “well, what do I do with all my modifications?”.

Err, excuse me? So this is perhaps what the ‘worse hit’ FUD earlier was about. Disaster? Far from it, Shai, far from it. In my not so humble opinion, a major part of SAP’s success was precisely *because* of the Open Source nature of the application code it delivered to the customer. Shai distinguishes two levels of ‘open source’ – a ‘read-only’ level for debugging, and a ‘read-write’ level for modifications. So let’s go with that and address each level in turn:

‘Read-only’ – one of the reasons SAP’s support departments didn’t get as swamped as they might with customer questions (stemming from, for example, incomplete documentation) is because the customer was able to look at the code, debug what was going on, and work out for himself what was supposed to be happening. And rather than having to contact SAP to ask for custom modifications, in many cases they could simply copy the code into their own namespace and make the modifications they needed.

‘Read/write’ – far more important than ‘read-only’, this allowed customers to not only modify the code to do what they wanted, but also to fix code from SAP that was broken. Not only that, but they could then send the fixes back to SAP to be incorporated into the next put level / hot package / service release. SAP benefitted (and continues to do so) enormously from this angle.

I remember even back to the late 1980s making a major change (well, rewrite) to an asset management batch program in R/2, for which we had of course the source – in this case, 370 assembler. The problem had been one of performance, and we had the author of the program visiting us from Walldorf. After my changes, the program ran orders of magnitude faster, and the chap (rightly) took the code changes back with him to SAP. This is just a single example. I’ve lost track of the countless fixes I and my colleagues have supplied SAP with over the last 18 years. I don’t begrudge SAP these fixes at all; after all, they’re programmers too (although SAP support these days leaves me somewhat cold, but that’s another story).

So the benefit — to SAP and to customers — of having read/write access to the source code is HUGE. As someone who has wrestled with SAP software for this length of time, I can’t stress that enough.

And so there’s a, in our industry there’s a very interesting balance that you need to keep; there’s certain things that you need — it’s almost the difference between what happens in the CPU and what happens outside the CPU for Intel. You don’t touch the transistors inside the CPU because, you know, you want to make sure your divisions always work correctly.

Ok, nothing really to comment on here, except to say that the parallel between source code and electronics, while on the surface seemingly reasonable (both ‘high-tech’ and ‘computing’ related), is in fact fairly inappropriate.

We’re going back into a model where we’re going to take some of that code that was open in the past and put it more into a closed box and put web services, well defined, documented service interfaces to that, and then say above that, you get open. Above that you get open models, you get open source, you get everything you want in order to modify.


Hold on there a second. Out of everything that Shai said in his answer about Open Source, this is (to me) the most worrying. Let me repeat what he just said: “… take some of that code that was open in the past and put it more into a closed box“. Let’s just make sure we understand what he said. It’s fairly clear cut, especially as the sentence that follows pretty much closes the deal: “Above that you get open models, open source“. Above the closed boxes. SAP is going to take some of the source that’s been open, and close it. Remove the open access to it.

I don’t want to appear alarmist, but this is alarming in the extreme. Software that SAP has delivered ‘source open’ in the past, will be delivered ‘source closed’ in the future? Well, that’s what he said. And we’re seeing that already today. Let’s step out of the assembler and ABAP world for a second, and into SAP’s J2EE world. Hands up those of you already frustrated with SAP only delivering software in compiled classes, without the Java source? Right. This is already happening.

This, then, is a potential watershed in the SAP world. Whether you agree with Locke, Searls, et al., business is a conversation. SAP’s business has been delivering applications, in the form of software, to its customers. And those customers have taken part, to their and SAP’s great benefit, in a conversation at the software level.

So SAP, and Shai, if I have one plea, it is this: do not deny a major reason for SAP’s success in the past and present, and do not close the doors on your customers in the future. Thank you.

Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Former Member
      Former Member
      Thank you for expressing exactly what I thought when I heard about this interview. Without access to the source code and the ability to modify it, a lot of projects wouldn't have been possible at all. SAP would be just another software vendor. And you are absolutely right about the benefits for SAP in decreased support questions and input from customers about possible enhancements.

      SAP did a great job with the modification assisstent to keep the modifications managable. That some mostly big customers made too much modifications is not SAP's fault and not a problem of the approach.

      Hopefully we can forget about all this. E. g. The source for ESS and MSS web dynpros is available, although it's ridiculous complicated to get it into the Dev Studio.

      If Shai Agassi thinks that customers can hook into SAP code to make their enhancements (e. g. with BAdIs): Without being able to look at the SAP code that calls the customer code it is nearly impossible to make use of the extension mechanism. And often there is no BAdI available for the requirement that you have. Waiting three years for a development request to get implemented and delivered is not good for the project schedule...


      Author's profile photo Former Member
      Former Member
      Agree completely with Christian and DJ. We have been discussing for a long time with my colleagues this change of direction that we' ve already noticed.
      Just add some things: decompilation of PAR project doesn't work always well with the available decompilers and it's necessary every time to recreate the project structure from the PAR file (in the case of java iviews) in  the ABAP case the code is there.
      In the comments of this weblog somebody talks about the future of services. I never I have been able to make a BAPI working without seeing what was doing inside (the doc were incomplete or only partially useful).
      I often heard  IT staff of customers that are not really happy of that they are loosing the Huge advantage that they got (transparent box) which made the difference on the past, just compare EP with an R/3.
      I would heard DJ and I would be careful on this change of direction it would have a huge impact on the customer side, and not certainly positive.
      Author's profile photo Martin Schlegel
      Martin Schlegel
      I fully agree with DJ, Christian and Fabio, and I would like to stress the point of documentation: Even if there is an excellent documentation, I personally like to read the source code as well, because reading the code and the doc is for me the fastes and most efficient way to understand a programm.
      Author's profile photo Former Member
      Former Member
      Regarding the Java side of SAP I completely agree with you. And I bet I'm not the only one spending a remarkable amount of my working time on decompiling SAP's JARs and classes for figuring out why things don't work as expected. Fortunately, Java gives you this option.

      Just my 2c,

      Author's profile photo Detlev Beutner
      Detlev Beutner
      Hi Dominik, hi DJ,
      first, DJ, thanks a lot for this great discussion weblog. *That's* the level I like to read in this area! And it's great to have a profound answer on the very general weblog of Shai. Thanks again!
      Now, my hands up, too, with my Java world experiences. You've given a nice example how SAP obviously benefits from it's open source in the ABAP world. As Dominik stressed, in the Java world we're always busy with decompiling (this especially holds for the EP); and I think, when I pass an OSS message saying "this is broken, the reason are lines 577-579, where ---" nobody gets angry that I have been that venturesome to decompile the code. In addition, there are customers out there, who *want* this and that functionality. They are not interested if this will be implemented in 2010, they want it *now*. And even if they know about the pitfalls of modifications, they appreciate that there are consultants out there in the world, having the ability to make the desired changes / implement the whished add-on's.
      Last but not least: No company in the J2EE / portal world has that bad Java/APIDoc SAP has. The documentation in general has been getting much better within the last 1.5 years, but the APIDoc in general is dire. We just have been sitting together with SAP for documentation issues yesterday, and we have been asked if the stress should be put more on general documentation or on JavaDoc's - my answer has been: That's like asking me if one should kill my mother or my father.
      And when I hear then that things should be "black boxed" and to balance this, interfaces will be given and well documented - I'm more than sceptical.
      So, my thoughts on this, best regards
      Author's profile photo Thomas Jung
      Thomas Jung
      It seems interesting to me that we have this discussion about altering SAP source code.  Shai's comments ("And you're allowed to modify them, which causes the worst disaster in our ecosystem") seem almost ironic in light of the some of the new features in the ABAP stack of NetWeaver04S:

      SAP is delivering some very nice new tools to make and manage enhancements to the delivered source code. 

      Tools such as the Source Code Plug-In and Implicit Enhancement Points seem to be going in a very different direction than the statements that Shai made. 

      What I take from the delivery of these new tools is a different message.  SAP isn't say we are going to close our code and not let you modify it.  They are just realizing some of the dangers in doing so and then giving us better tools to make these changes (at least this is what I hope this means). 

      Author's profile photo Peter Inotai
      Peter Inotai
      Hi Thomas,

      I hope you're right. Hiding ABAP code would make no sense for me, it would make troubleshooting very difficult. From the other hand it would increase significantly the workload on SAP support during problem fixing.

      To motivate customer NOT to change SAP standard code, I'd rather make some restriction on the registration key request process.

      Playing around with EEWB - Easy Enhancement Workbench in WAS 6.40 and checking the mentioned documentation (BTW there is a great SAP Insider article about the topic in SDN from Karl Kessler) it seems will make great improvements on this area, which can makes Upgrades less painful.

      It's a pity that Enhancement Framework in ERP 2005 mainly focuses only on Industry Solution so far...and of course that no downport is planed for this tool (which I can understand due to the kernel dependencies).


      Author's profile photo Benny Schaich-Lebek
      Benny Schaich-Lebek
      Hi DJ,
      well, if all our customers would be of your character, like noble people who correct our software and give this to us for free (and I *mean* it!), then the open source aspect would be far away from being a problem. Unfortunately reality is different from that. As you surely know better then I do (being an ABAP specialist, which I'm not), software upgrades come along with a nice check of your existing software to find out if you did do any changes.
      Smart people, like you are, calculate with that and design their work in a way that updates won't harm them that much. Less smart people may find a screen during update that tells them -as the story goes here at Walldorf- what they've done ultimatively wrong:
      "7420 changes found in software. Please compare line by line with update for logical correctness"

      Once the child fell into the well (/german phrase) we can legally correct withdraw our support from this, but that would leave a bad taste and so, more then once there have been found solutions that help those unlucky delequents and produce cost for SAP.

      A word about Java: the point here is that there currently is no major business application running in Java, and the ones that exist all are delivered in code (to my knowledge). Most Java stuff is technology that we would not like to be changed by our customers - Unlike I don't doubt that many of you could do this to the better of the product.
      Unfortunately this concept only works with real open source, as we cannot accept code changes from customers (assume something like a transport system that lets you forward changes to SAP)for legal reasons.

      And an additonal word about ABAP in special: I really doubt that Shai wants to close your access to the code as it is today. As you know we are going into the direction of services. Those services shall be standardized and may be available over the borders of your company systems. In that case it is absolutely necessary that this piece of code is everywhere the same - meaning: no code changes possible (what wouldn't stop your of copy and change it and give it another name)
      As Shai always has to deal with vision and reality systems at the same time, you may forgive him the slightly inaccurate formulation.


      Author's profile photo Former Member
      Former Member
      Here's a quick example to help support Shai's vision of open source(the SAP way).  In CRM's IPC Server(Pricing Server) which runs on a J2EE and is obviously written in Java, SAP has extended their concept of ABAP "user-exits" to the Java world.  They give you a "stub" java file where you can write whatever code you want to manipulate their structures, data itself, or even make up your own logic.  Then you simply compile the code and deploy to their server.  This is the fully supported method that SAP has provided to give users full control of their routines from within Java, but doesn't clash with the rest of SAP rigid system.
      Author's profile photo DJ Adams
      DJ Adams
      Blog Post Author
      Hi Alexander

      While the IPC *GUI* components run on a J2EE platform, the IPC server, while written in Java, does not. It's a pretty straightforward dispatcher/server setup, with registered RFC hooks into the CRM system.

      I'm aware of how the customer exits work with the IPC server; we're using some currently, in fact. And by any stretch of the imagination, offering stub files and exits, while useful, is very distant from (so as to be entirely unlike) any version, or "vision", of open source.


      Author's profile photo Former Member
      Former Member
      Hello Benny - hope you are well.

      I feel compelled to answer this one, so I hope DJ doesn't mind.  Points are made inbetween yours, below.

      Context: "Once the child fell into the well (/german phrase) we can legally correct withdraw our support from this, but that would leave a bad taste and so, more then once there have been found solutions that help those unlucky delequents and produce cost for SAP."

      SAP can easily push even this level of support back onto the customers in the form of consultig fees - thats standard practice, and I don't buy the cost argument on that basis.

      The idea of Open Source is - sure, I give you theses scissors, now it's up to you whether you run with it or not.  This ideology is fundamentally rooted in Open Source, and the the innovation potential that it generates.  Put simply - the more you restrict what people do, the more you inhibit their potential to innovate, the more a product stagnates, the closer your competitors are on your heels ...

      Context: A word about Java:...

      It is presumptious to state "Most Java stuff is technology that we would not like to be changed by our customers".  The old ideology that SAP subscribed to by opening its source code in R/2, and R/3 was much more "This is our product and we think its great, but we don't know where it might go, or what might be wrong with it.  Our customers, can (and did a heck of a lot) show us where this baby can go, and we're all along for the ride, because the benefits of working like this far exceed the detractions".

      Context: And an additonal word about ABAP in special:...

      This smacks of Ivory Tower syndrome.  To think that SAP holds all the keys to the functionality and interfaces out there, and that they alone can determine what they should/shall be, is doom incarnate.
      Time and again the industry comes up with surprises, as to what will happen next.  We need look no further than Google, eBay, and Amazon.  People have made fortunes out of reorienting their business overnight, to take advantages of these phenomena - impossible to do if you had to wait for your "API keyholder" to Grok it.
      Standardising services and their APIs, and restricting the ability to innovate them will turn SAP into a silo that will some day be out manouvered, taking away its customers competitive advantage with it.

      Open Source works, and because it works is gaining momentum in the market place, despite the competitions "best" efforts.  As it stands, there are independent efforts springing up in every sector of the industry, even in the traditional ERP arena.  Everybody has to deal with this, or lose the fight, so it wouldn't surprise me, that even SAP will be completely Open Source one day, after everyone has figured out how to compete in this new era, and the perceived value has been pushed higher up the stack.

      Author's profile photo Benny Schaich-Lebek
      Benny Schaich-Lebek
      Hi Piers,
      thanks I'm well and my best wishes to you also...

      What I said about Java was meant with emphasis on "technology": we never delivered technology in an open manner, in ABAP that was (and is) the kernel which is written in C and compiled.

      And yes, we do see that Open Source makes products move. And there is thinking inside the company about this - and more I don't feel authorized to talk about.

      Piers, I'm sorry that I have to tell you that the 'Open' aspect of ABAP was not planned the way it is today. To my knowledge (I wasn't there) it was merely enforced by large customers who saw potential there. This forced SAP to make all those tools that enable that environment (the transport for example). You bet this was not produced without cost...

      Open Source works so far in specific markets. It has taken over more or less the devlopers world. But I still wait for significant success on the desktop for example. And despite the fact that there is a couple of nice Open databases out there for quite some time, there still is no real shift in the market.
      Not that I doubt it will ever come!
      But before this happens I think we have a long way down the road.


      Author's profile photo Former Member
      Former Member
      It would greatly suprise me if the Open aspect of ABAP (as you put it) was wholey enforced, and not seen as an opportunity, as the opposite of that would have been seen as "giving the family jewels away".  Perhaps it wasn't as farsighted as I would hope that SAP was, but there is no denying - and I would challenge anyone to this - that it hasn't been a runaway success for SAP.   Just think - hundreds, prehaps thousands of developers from your customers pouring their eyes over your code, and telling you for free (no - actually paying you for the privelledge in many cases) whats wrong with it!  The truth is stranger than fiction sometimes 🙂
      Open Source has started from a developers world, but then that is because Alpha developers often Grok where the world is going before the Investers  do - actually, I believe that there is even some resonnance with SAP's beginning with respect to this (insert a history lesson about how the founders started out here).  As for the desktop - even this is starting to feel some pressure through a combination of chronic security problems on the incumbent side, and a maturing of the core user tools on the other  (Open Office, Firefox, Gnome, etc.) - try Ubuntu ( for example - I even have it running the SAP Gui 😉
      In the Enterprise application sphere - just try googling for "open source erp" - the mere fact that anything of substance appears here at all would have been unthinkable a few years ago, but now ...
      So yes indeed, we shall see what happens, and how long it takes.


      Author's profile photo DJ Adams
      DJ Adams
      Blog Post Author
      Hi Benny!

      I'm sorry to tell you that what you wrote on the "enforcing" of ABAP's openness is not particularly accurate.

      We have to look back to how the applications were delivered pre-ABAP - in an open source way (you could see and change the source code). Then ABAP came along - ABAP/3 (yes, 3) was introduced as a report writing tool, to be coded in DD statements in your JCL. Indeed, ABAP stood originally for "Allgemeiner Berichts- [und] Aufbereitungs- Prozessor". It was meant for end users to write reports with; at the time, it was purely LDB-driven - no SQL, not really a reflection at all on what ABAP is today. Later in R/2 SAP started to deliver some online (dynpro-based) applications in ABAP/4 (as opposed to assembler). So there wasn't really any 'forcing open' of ABAP - it was open from the start.

      And I must pick you up on the spurious (but nevertheless often-used) argument that goes along the lines of "Open Source is nice but it's not really mainstream". Apart from being rather patronising (whether you intended it or not), it's misleading, nay, specious. Tell me Benny - what is the largest distributed application in the world? Of course - the Web. And upon what is the Web *predominantly* built? Err yes, correct - Apache, Linux, MySQL, Perl, Python, PHP ... the list goes on. And guess what all these things all have in common?

      Yes. 🙂


      Author's profile photo Former Member
      Former Member
      I would like to put another point of view on this. I am not sure, if we are fighting on the right battlefield.

      When I look at the direction that SAP is going with its development tools and environments, the future points towards model driven development. Still in their toddler-phases (walking, but often stumbling), the Composite Application Framework and the Visual Composer both create models, that generate coding out of templates. The models are the pieces that are and will be shipped to customers. That means the coding is completely open (it's generated), the templates are view- and editable and the control and ownership is completely on the customer side.

      A good example of this paradigm is good old BW. Who on the customer side is really changing the generated coding for the analytical applications? What's done is model development and some code added to the extension points in the e.g. transfer or update rules. And they are able to create full blown applications  in large varieties this way.

      We will see this in the upcoming years to be the same with business ("transactional") applications, when more and more of them are not really "coded" anymore, but generated from models. That's what I read from Shai's quote (I focus on his second sentence as a result from the first):

      [i]We're going back into a model where we're going to take some of that code that was open in the past and put it more into a closed box and put web services, well defined, documented service interfaces to that, and then say above that, you get open. Above that you get open models, you get open source, you get everything you want in order to modify.[/i]

      And exactly this quote also tells me that "Open Source" becomes less important than "Open Interfaces". What's the value of Open Source, if I cannot access this piece of application from outside?

      At least that's my interpretation of Shai's comments...



      BTW: I know of course the pain, of not having source code available on the customer side from the perspective of a development manager, whose developers have to do support.

      Author's profile photo Former Member
      Former Member
      I'd agree with Mario's view on this one. Rather than interpreting what Shai said and what he meant, we can already see a lot of focus on MDAs and code generation. Check out David Frankel's views on this one at [original link is broken] [original link is broken] Moreover, if we see the roadmap for BPM and ARIS, it is highlighted that ARIS will be embedded in NetWeaver in times to come. That means communication and customization happening at process architecture layer rather than process execution layer.

      The focus thus shifts towards improving the toolset, making sure that it generates and deploys the desired logic in the best of manners. Having said that, I am sure no one will be able to deny the importance of the option of viewing and modifying the code whether written or generated. Extension points are a nice to have feature but they are built on the premise that the rest of the component logic is correct. This premise is pretty much followed across all programming paradigms whereby we are are willing to work with APIs. If the underlying platform is mature enough, layer it and move forward.

      My 2 cents...



      Author's profile photo DJ Adams
      DJ Adams
      Blog Post Author
      Gruss Gott Mario

      Open interfaces are important, but only *in addition to* open source. As long as software is distributed (to customers), this matters a great deal.

      You make a point about model driven development - but we all know the nightmare of debugging horrendous generated code; this is only going to get worse as SAP software becomes more and more complex because less and less of it is written by humans. Who's going to fix this stuff, debug it when it goes wrong? Closing the source is just closing one's eyes to the problem, not addressing it.

      You mention "interpretation" of Shai's comments. As far as I heard and transcribed, there's little open to interpretation; no matter how much people try to bend his words to whatever meaning suits them, it's all there in black and white - what he stated is pretty clear.


      Author's profile photo Former Member
      Former Member
      Don't mean to pick at the small details.  Just wanted to clarify.  Anyone can view the "source" of the compiled java classes SAP delivers.  We've done so on a few projects, and even made our own version of them on occassion.  There are many tools freely available to do this.

      Good article...


      Author's profile photo Detlev Beutner
      Detlev Beutner
      Hi Max,
      as it has already been stated in the comments of this weblog that it makes a difference if all classes are only there compiled or with sources (i.e. with comments!!!).
      Compiled classes (without sources nearby) are closed source. It makes a difference if the door of your home is open - or closed and I have a picklock at hand...
      Just wanted to clarify 😉
      Best regards, Detlev
      Author's profile photo Former Member
      Former Member
      Hi DJ,

      Like other people/companies I'm still working with a 4.6 system with an upgrade looming in the future.  And after reading this weblog I agree that to "close the door" on source code within current/future releases of SAP would have a negative impact on both SAP and its customers in ways that you have already described.

      I think its great that there is a forum like this where SAP employees and customers can discuss such issues and its evident that people are getting involved by responding.

      Let's hope that SAP evaluates the situation to do what's best for their customers.

      Great weblog!


      Author's profile photo Former Member
      Former Member
      Shai is right about source Code. Making the 'Open Code' to 'Closed Code' is to hide implementation details. SAP is going towards Object oriented. According OO design rules, one need not know about how the code is implemented within the box, one should be interesed in what is available to operate the box.

      Guys, dont make Shai comments a big deal. I suggest you to read and refer to his comments in relation to 'OBJ Oriented' World not in an ABAP world.

      Think about it and read Shai's comments again.

      DJ ADAMS complaining about Shai not replying to this blog, I dont see any reason why Shai has to reply where it his comments are 'Completely taken out of context even by one of the experienced veteran SAP Coding Guru'.

      I would recommend to read about 'Encasulation' under Object Oriented world once again.

      I dont mean to disrespect anyone with my comments.

      Positively thinking always,

      Author's profile photo Detlev Beutner
      Detlev Beutner
      Hi GO,
      if you'd had deep experience in developing EP solutions, you would no how wrong your statements are. A good EP developer probably will use about 20 to 30% of his time to decompile, read and understand the sources to learn how this and that is implemented (or to modify some things, or to check where a bug is hidden etc). All this is already discussed in this blog (scroll down).
      Anyhow, I just wanted to point to an article just published in "blaupause" 1/06, the magazine of the DSAG: "There are good reasons to deliver the Java source code!" (it's only in german; written by Dr. Clemens Fischer, speaker of the SAP NetWeaver Development ABAP and Java research group within the DSAG).
      Regards, Detlev
      Author's profile photo Former Member
      Former Member

      Being a 'GOOD' EP Developer you should be able to understand by now that SAP EP or any of NetWeaver products are not 'OPEN SOURCE'.

      FYI, we were discussing about OPEN SOURCE not abt EP.

      Decompiling Java is necessary in some cases, as a Java Developer I agree on that aspect.

      Could you help SDN community to translate that article to read in English (you suggested above), if I may request you.

      Thank you,