Many partners and customers would like to have source code access. This access could be read only but it would give them an additional tool to understand behavior and determine if certain requests can be accomplished. Idea Origin: Sage Summit - C-0179 Influencing the Design session
Guest
To make reasonable, hopefully acceptable thought/proposition ; considering the IP background of such topic for Sage ;
There are typically 2 kind of source code to distinguish :
The source code of the Sage X3 engine (or assimilable as Syracuse, print service, etc.)
The source code of the business' functions which runs over the configuration we can achieve on configurable lements from the ERP (objects, classes, models, ...)
Regarding the first point, I can fully understand that this is not to be shared with partners or curstomers ; as this is the most valuable part of the Sage X3 product. Please note however that, despite this is not a rocket science to create a framework to facilitate development (what Sage X3 does really good aside the standard functionalities provided), no one would seriously think to take rebuilding this part on his own facing all of the problems in term of compatibility (OS, Database, WebBrowser, Security, ...). But anyway, let's consider this is better not to share outside Sage's internals.
On the other hand, the 2nd point is more arguable. Indeed, anyone who already has worked/developed in ERP context know that, as example, a sales order is linked to a customer, a customer has itself for example an address, and so on. Clearly all these "parts" are, in term of concept, evident things ; and is finally only assimilable to boilerplate code. One who would make a concurrent product to Sage X3 (I think pov of Sage is here) would not need source code for that, only looking at visible part of UI and user documentation is enough ; moreover considering the old-style of source code being discussed here (not a criticism, that's normal regarding the product's whole longlife).
In this context, Sage current position to not share seems, imho, a non-sense. Lone people really penalized are finally partners and customers., decreasing the attractivity or the product. Indeed, if you have a process to structurally modify aiming to better fit your business cases (standard processes implemented give no advantages between Sage's customer themselves beacause they all use it the same way), you're usually stucked by internal code which block at either or else place you cannot investigate or get L3 support for ... and you finally implement new processes outside the standard, decreasing the use of standard functionnalities.
Yes, it'll be very usefull to understand the logic behind script
This would help us to understand the logic written behind the functionality and if there is any similar customization request from the client, we can easily refer the code for our reference.
This would be very helpful