Crack Addicted Invisible Hand

Posted in innovation, SAP on December 9th, 2007 by dan

In Scoble’s blog Why enterprise software isn’t sexy, he asks a simple question, “Any of you have any ideas on how to make business software sexy?”  A lot of my fellow Enterprise Irregulars have taken Robert to task about this, saying that it is in reality sexy:

“[B]eauty and sexiness is in the eye of the beholder… [seeing] UPS give each one of its drivers a DIAD – and they did it years before the recent wave of personal gadgets – with GPS, wifi, scanning and other technologies. And with a battery that lasts all day. Can our iPhones do that?”

Vinnie does a great job showing how underneath the ugly exterior enterprise software is amazing and sexy.  Most of these posts are all missing the important comparison Scoble is making that Nick Carr picks up on here:

perpetuating a false dichotomy between the friendliness of consumer apps and the seriousness of business apps, all that Krigsman is doing is giving enterprise vendors cover for continuing to produce software that’s difficult and unpleasant to use

The post from Michael Krigsman(which although Nick beats up on chooses not to link to) talks about, how all this isn’t relevant because enterprise software is “intended to “enable core business processes” with a high degree of reliability, security, scalability, and so on.”

Enterprise vendors need to be keenly aware of the consumer market but, SAP’s customers don’t pay them to run around like Scoble and chase every new technology/website that comes out.  They pay them to make measured, smart choices with what they create and how they spend their R&D money.  Their customers do indeed expect the software they create to have a “a high degree of reliability, security, scalability.”

Enterprise vendors have an advantage – they can ride on top of the frothy startup market cherry picking things that work well and will deliver value back to an enterprise’s bottom line.  In the consumer tech industry, the invisible hand of the market is addicted to crack and has the attention span of a two year old.  The consumer market is chaotic, jumpy and prone to fickleness.  Online companies/ideas are created and destroyed everyday, and it is up to Scoble and other followers of tech to survey what’s out there, they need the thousands of readers.  The two industries have totally different business models, Twitter needs millions of users to monetize their software, SAP is very profitable on about 40k “users” world wide.

This shows the Enterprise software market is much more focused and so is their advertising.  Dan Farber does an excellent job of handling this topic and refocusing the discussion on what Gates actually said:

The business computing market, which is way bigger than the consumer computing market, no one pays attention to it. Even in the Wall Street Journal, and you think, oh, this is the paper they’re going to tell me about business computing; no, it’s all about consumer computing

LiveSide.net – Bill Gates, Mix n Mash, and the future of Microsoft

Dan goes on to point out why ZDnet covers enterprise topics:

We recognize that in the 21st century you cannot easily separate the two, given technology is deeply embedded in work and personal lives… [T]he financial equation is not just about page views or number of readers–more important is the quality of readers we draw into the ZDNet orbit

Who am I to contradict Dan when it comes to the determination of advertising revenue — after all he is the Editor in Chief of ZDnet.  In the advertising arena you can also point to things like SAP sponsoring golf stars, tennis pros, formula one cars, etc.  Who watches these things?  CIOs, and other TLA execs who make these decisions.  If SAP cared about CPM they would advertise with NASCAR.  Let’s just give SAP the benefit of the doubt that they understand their market more then Scoble.

I couldn’t agree more that Enterprise vendors need to make things easier to use and an all around friendlier experience but, they need to be smart and measured because that’s what their customers want.

Secrets of the Subscription EULA

Posted in ABAP, SAP, SDN blogger on October 17th, 2007 by dan

I was able to ask Zia Yusuf this morning about some of the restrictions around the SAP Subscription License.  paraphrasing his answer a bit:

The license you are granted is a development license if you intend to resell or license any of your solutions you create you need to get a different license from SAP

So what this means is that if you develop something on the subscription program you cannot resell it.  The EULA is pretty clear in this regard:

If You wish to use an Add-On or Consuming Product Application created by You in a production environment, or to otherwise commercialize and/or distribute that Add-On or Consuming Product Application, You must first enter into a separate agreement with SAP.  Under this Agreement You are not entitled to: … license sell, offer to sell, transfer, rent, lease, distribute and/or otherwise make available the SAP Software and/or any Add-On to third parties. [source: EULA]

Thanks to Eddie for the link to the EULA.

Basically this means if you want to sell something you need a new license and probably any open source work would also meet with a cease and desist from the SAP legal team. 

To compare this to another player in the industry the EULA associated with the MSDN subscription appears to not make any distinctions like this.  Granted the pricing for the MSDN subscription is a bit higher, New $10,939, then $3,499 / year thereafter.  Compared to the SDN Subscription cost which is $2,300 / year.  I wonder how the MSDN numbers compare with the cost of the SAP license to resell your solutions.

I think the subscription is a great idea and a big step forward for SAP but, to become a “platform company” they need to make it easier(cheaper being part of this) to get started in the ISV market.

Majority Desk Architecture

Posted in Flex, innovation, SAP, SDN blogger on October 9th, 2007 by dan

One of the common questions I was asked after demoing Majority Desk was how the heck is it built?  To explain, I will first break down the individual components and then talk about how the Wiihands move across the screen.  There is a lot more to the interactions in this system but, moving the Wiihands should give you a pretty good insight into how the whole thing is built.  Just to frame the following discussion Majority Desk is mostly an AIR application built using Flex Builder 3.

ODE2Paper

ODE2Paper is the main visualization and physics library I wrote that underpins the Majority Desk application.  It binds the Open Dynamics Engine (ODE for short), which is the underlying physics system to Papervision3d (PV3D for short), the 3d rendering system.  The foundation of this interaction is actually very simple: every time Flex fires an ENTER_FRAME event I issue a refresh command over a socket that is connected to the physics server.  The physics server is a python application that uses pyODE to wrap the ODE libraries.  The physics server “parses” the refresh command,

<refresh/>

iterates across all the objects in its world producing a new XML document with the position and transformation matrices of all the existing objects and sends that XML back to Flex. 

<world> <o1 x="0.0" y ="0.0" z="0.0" r0="0.0" r1="0.0" r2="0.0" r3="0.0" r4="0.0" r5="0.0" r6="0.0" r7="0.0" r8="0.0"/> <o2 x="10.0" y ="15.0" z="10.0" r0="0.0" r1="0.0" r2="0.0" r3="0.0" r4="0.0" r5="0.0" r6="0.0" r7="0.0" r8="0.0"/> <collisions/> </world>

When this data transfer is complete on the Flex side, I move all the objects in the PV3d scene and then call the camera render.  Simple right? :-)

A Wii bit of background

The Wiimote is a blue tooth transmitter, it reports its position and state to the blue tooth receiver on the client computer.  It determines its position by “looking” through the IR port on the front of the Wiimote at the poorly named sensor bar.  The sensor bar in reality has no sensors in it — it has two IR emitters that allow the Wiimote to triangulate its X and Y position in space.  The Wiimote also has an accelerometer on board that allows it to measure movement in the X, Y, Z planes (pitch, yaw, and roll).  This page has a mountain of technical detail about the Wiimote.

WiiFlash

The information from the Wiimote is sent to the WiiFlash server.  WiiFlash removes all the complexity out of using Wiimotes to control any Flash application.  The API is pretty complete and we found it to be fairly stable.  This is the section Eddie dealt with most so, I can’t talk too intelligently about it except to say that we use the WiiFlash AS3 API to access all the position and button state information from the Wiimote.  The API handles all the calls through a local connection that streams the information from the projects WiiFlash Server, which for now only runs on windows, sorry Mac faithful. 

This pretty much rounds out the subsystems that lie underneath the application.  This doesn’t really explain how the thing works so, I will walk you through how the Wiihands move around the screen to hopefully give you a better idea of what is going on.

Moving Wiihands

The most common thing we do in Majority Desk is move our Wiihands to interact with the world.  To allow interactions with the state of the physical world maintained by the physics server we have a set of commands in ODE2Paper.  The ones that matter for the Wiihands are createSphere, setObjPos, createJoint and breakJoint.  These methods serve as proxy for the real commands flying over to the physics server.  The rationale for this is again the main underlying concept that the physics server knows where the objects are and PV3d simply renders them.  So all the interactions are really taking place on the physics server.  The Wiihands are represented in the physics system as sphere because they are in reality just a cool texture wrapped on a sphere in PV3d.

So as a Wiimote moves we get its position and call a setObjPos method in ODE2Paper library which moves the object in the physics server.  Again the physics server leads and PV3d simply renders a view of the world.

Grabbing stuff

If you got the chance during Hacker Night or our Meet the Jammers session to mess with Majority Desk you may remember that if you hold the trigger and bump into something with your Wiihands you can grab it.  Letting go of the trigger will release the object and let it float around again.  This is achieved using the collisions XML node that I didn’t talk about earlier.  If you look back at the XML doc that the physics server creates to represent the world you will see an empty node there for collisions.  ODE2Paper notifies our Flex application that two bodies are about to collide via this XML node.  This allows us to detect that the Wiihand is touching something and then build a joint, using the ODE2Paper method createJoint.  A joint is a type of attachment between two bodies in ODE, we use simple static joints but a whole slew of different joints types are supported by ODE.  This is why the widget seems to follow a Wiihand around as it moves.  The great thing is this affect is achieved by just calling setObjPos on the Wiihand, which is the normal behavior described previously.   To release the object we simply call breakJoint and the physics server breaks the joint allow the attached object to move fluidly again.

If you want a run down of links and a good video that shows Majority Desk in action, check out Eddie’s blog post about it.