Skip to Content

Widgets and Trust

One of the first challenges I’ve been trying to tackle on the topic of widgets is the concept of “trust”.  If we have people publishing their own widgets (as I hope we do), then end-users and IT professionals alike will need some way of knowing whether or not to trust a widget before and during installation.  Here’s what I’ve been thinking so far. Let me know what you think about it.  In an early internal experiment here at SAP we made some mistakes that would have allowed another widget to hijack the user’s credentials- handy for giving yourself a raise, but horror show for us.   As a result, we realized that we’d better make it easy to create safe code and introduce pre-built libraries for handling user credentials and data transmission.  Look for these coming soon from Fred Samson.  Eventually, we’re looking to provide a small footprint client-side enterprise widget service provider that will run alongside the widget engine.  Since that’s entirely too long of a name and it doesn’t spell anything snazzy, lets call it “Foundation” for now.    In addition to providing a service to handle user credentials and data transmission, Foundation will also afford end-users and IT folks a method of validating “trust”.  Here’s how it might work: when an enterprise widget is installed, the Foundation checks to see that the widget correctly uses the Foundation services and doesn’t install components directly on the OS).  If everything checks out, the Foundation will pop-up a nifty SAP branded dialog saying that this widget uses SAP authentication and communication services. This won’t ensure that the widget will provide good data or accurate results, but at least it won’t expose private data or mishandle user credentials.  I compare this to what Verisign does.  Verisign doesn’t prove that a website won’t rip-you off, but it does ensure that at least the publisher is who they say they are.  At a Web 2.0 event I attended last week, a large financial company confessed to me that they “want someone to sue in order to trust something”.  If this feeling is widespread, I’m thinking about providing a SAP code certification program.  This sounds expensive, and probably will be, but for those customers who want to rely on a 3rd part vendor to provide a tool for their customers, then this will be the way to go.
You must be Logged on to comment or reply to a post.
  • This is a something that has always concerned me.  Will people ( enterprises ) not adpot open source solutions due to not having the ability to “pass the buck” ( in this case, the law suit ) onto some vendor poor unsuspecting vendor.  The GPL totally indemnifies the author from lawsuits, “BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. [It is provided] “AS IS” WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, … FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU.”  I guess my greatest fears are true — people won’t use products unless there is someone at the other end they can sue when something goes wrong.  I would say this is a truly sad day. 


    • Daniel,

      But this is not the only model!

      Some open source projects have dual-license model, GPL + commercial, with clearly defined vendor and gurantees in later case.

      Also there is open source + commercial services, like ones provided by JBoss. Here the risk is mitigated as well.


      • The point here is that, it appears there MUST be a corportate entity at the end of the Open source model to sue.  That point is reinforced by our example also.
        • Daniel,

          It’s more complex that you described, the actual risk depends on type of license and size of code you get.

          Say, license is BSD and size is approx. several man-months. The risk is sounds quite acceptable — even if original creator of project stops to support it, both license and size allows you to manage the codebase yourself.

          Now if we consider aggresive GPL licensing model and large codebase then there is only one option — either you have a commercial entity and dual-licensing or risk is unacceptable.

          LGPL stays somehow in the middle, typically you may not alter original code, so this is quite distracting. On other hand, if existing code is stable enough you may evolve your own code around it.

          From my own expirience, there were some cases when author stop to support (rather small) libs, and it was possible either to contact him directly and buy the lib, or just mention the lib origins in docs.

          The only OSS project that warns me with its misbehavior is Apache Jakarta. I can count 5-7 libraries of different size that they abandoned in 5 years. Or replace them completely, if you can say that VFS(Virtual File System) is a replacement for Slides (WebDAV client). Anyway, Jakarta is not an OSS project, but rather an IBM research lab for recent time. Btw, the lab with very bad results, far worse then other IBM lab “Eclipse” 😉


        • Hi Daniel,

          Please take into account that it was a financial institution. Their whole existence is based on their good name and the trust that people have in them. That automatically leads to being very risk averse and rightly so.

          Put yourself in the shoes of an IT manager. Your job is on the line if something goes wrong. You want someone who has skin in the game who’s job is on the line too when you go under.

          Valery makes excellent points that there are other models with service agreements …

          Best, Mark.

  • “Foundation” sounds like a decent idea, but trust via code certification programs is a different beast.

    Trust in an open source project should come from community usage and acceptance of the product itself.

    My answer to said “large financial company” or any other company looking to sue someone would be that if they don’t trust it, either
    A) have someone from their own company validate the source code which is readily open and available or
    B) dont use it!

    If you are relying on a 3rd party vendor that you don’t trust, you should probably find another vendor.


      • Hi John,
        First off, I would like to say I really enjoyed your demos of the new scripting language tool in Vegas. I  still haven’t used the tool much yet, but what little I have seen works well. Will you be presenting at Amsterdam as well?

        Regarding your question above about the lessons learned, what did you have in mind?  I love the fact that some of the various SAP teams are looking to leverage an open source model by utilizing outside developers. I would much enjoy being involved in discussions or even development on some of these projects.


        • Hi, Edward

          the Scripting Tool you mentioned is a good example for this. We explicitely aim for it being used and extended by external developers. We already have an article in queue describing how to write an own generator. APIs might still change a bit, but we really want to involve enthusiastic developers as early as possible. So if you want to being involved I encourage you to contribute to the scripting community – and to the tool, as soon as we managed to make it available in source (minor legal things to clear first)