I'm in Berlin at SAP's Innovation Weekend, where we are introducing SAP Code Exchange, a portal for shared source projects related to the SAP platform.  For the first time, hundreds of thousands of professional SAP developers will have a place to find utility code and work together on bigger projects.  To build Code Exchange, we integrated SAP's developer network with a customized Assembla instance.

Open source code and processes are a key component of modern fast, lean, and global software development.  I like to think about practices, things that you need to know to get benefits from this component.

• First, you need to know how to do research to find and adopt appropriate code and frameworks.  That makes development faster.
• Then, you learn to contribute to open source projects, so your customizations benefit from shared maintenance.  At a company level, this leads to sharing code with customers.
• At an advanced level, you organize open source and shared source projects to support your vision of the world, your platform, and your users.   Every big software vendor will eventually have to learn and deploy these advanced processes, as SAP is doing.

SAP's Innovation Challenge

Project leader Rui Nogueira says "We built Code Exchange to encourage co-innovation, with innovations moving more quickly from customers to SAP, and from SAP to customers."  Kaj van de Loo, SVP of Technology strategy, talked about SAP's openness initiatives, and quoted Ronald Reagan, "tear down this wall".

Code Exchange was shaped to fit with SAP's shared-source licensing, their proprietary code management, and their active developer network.

SAP has a long tradition of sharing code, predating the open source movement, because when you buy their installed ERP apps, you get the source code.   Very cool.  In the license agreement, customer and integrators must agree to certain terms.  Code Exchange creates a compatible environment by asking all users sign a “terms of use” agreement that is compatible with the SAP shared source license.  Once they sign the terms of use, they get into a walled garden where everyone shares with common license terms.  They are breaking new ground with a type of shared-source licensing that can open up high-value, proprietary systems to the power of  sharing.

SAP apps are beyond the size that I can imagine managing, with about 150,000 screens.  SAP has specialized systems for version control and deployment to handle this beast.  We need ways to move code between their Netweaver development environment and internal ABAP repositories, and standard svn and git repositories.  For example, SAP advisor Gregor Wolf has been working with collaborators on the SAPlink import and export mechanism.

SAP has existing portals for their developer network, and the customer network (with 2M users).  They just released a new project collaboration environment based on Jive SBS.  The SAP team wanted to add repositories and ticketing, without confusing anyone.  Their vision was radical simplification.  We stripped Assembla down to one project template with just the extra tools they wanted – Subversion, Issues (our Tickets), Releases (our Milestones), and Chat.

What did we do?

So, how do we customize and deploy Assembla for an enterprise customer?

1) Start with our Private Assembla configuration.  This is a stand-alone configuration of Assembla without any of the subscription features, with source code.

2) Set up staging and production servers.  We got permission to use cloud hosting (see below) and started some servers in the Amazon EC2 datacenter in Ireland, bringing us inside the EU.

3) Fork the Assembla code into a new git repository.  With this structure and thoughtful engineering, we can easily merge new versions with our SAP customizations.  We also set up ticketing in this new space and invited the SAP team to work with us. We set up build scripts and continuous integration for the staging server.

4) Configure and skin.  We brought in a header and styles from the SAP Developer Network, as shown in the screen shot.  Strip it down to one project template and configure that template space.

5) We made a number of customizations, including: login/authentication to implement single-sign-on with their domain cookie; simplified start page;  release file posting; API authentication, and some API upgrades.

6) The Jive portal team at SAP integrated Assembla using the REST API.  They used the Space API to add matching projects, and the Tickets API to list  and post Issues, a subversion browser, and a new Milestones API to show current release files.

7) SLA and security compliance.  We asked for some adaptations to SAP's normal security policies, so that we could use cloud hosting.  We also took advantage of some of the work that Amazon is doing to meet enterprise security requirements. This is by itself an interesting subject, if you are involved in moving enterprise apps to cloud hosts.

Here's a video interview from Innovation Weekend.