Late last week I did a podcast with Jon Reed and Graham Robinson on SAP's developer engagement initiatives. You can watch that here.

This discussion, and the fact that I'm back doing some serious ABAP development after a lot of non-ABAP work, got me thinking about the value SAP's application ecosystem contains that developers would love to add to, to SAP's gain. But it's very difficult to add value in this ecosystem as a developer because of (among other things) the weaknesses of the ABAP development environment. What, I asked myself, would a truly strong ABAP development environment would look like. Here are a few thoughts:

ABAP system as a decentralized version control system (DVCS) node - An ABAP system should act as a true DVCS node. This is a good explanation of the nirvana you too could experience with a DVCS, with pictures of a cute dog. In short, an ABAP system should, at the package level or at the full system level, be able to commit changes, push those changes to a remote repository, pull changes from a remote repository, maintain branches, and merge (with user input if necessary) those branches. These descriptions use Git parlance, because that is what I know.
Branch and merge - Related to behaving as a DVCS, the ABAP system should be able to support full branch & merge semantics. I'm not sure how well I can explain this. I'll just tell you, it's a great feeling to have the ability to create a branch of a complex project, rip out an integral component, completely rewrite it, merge those changes back into the main development branch, and have none of the other 3 people working on closely related parts of the project notice any change expect that things just work better. I know. I did it last week. Oh, and I simultaneously made fixes as they were requested on other branches of the project and pushed those out to my co-workers while I was working on that rip-and-replace. Good luck pulling that off on an ABAP development system.
Namespaces - SAP should make namespaces available to open source projects for free, with minimal bureaucracy. And while you're at it, just do the same for everyone. What do I mean by "minimal bureaucracy"? A web form and account system that saves the namespace to a database after checking that no one else has already registered the same namespace. Why are namespaces important? They address the problem of naming collisions between development projects. Right now, the open source ABAP community mostly develops in the customer namespace. This is a recipe for naming-collision hell. But what other options do people have? SAP should to fix this, and fast. And while you are at it, make the namespaces versioned (see below).
Improve SAPlink & ZAKE, and include them in the standard distribution - SAPLink and ZAKE are the defacto standard ways to develop and distribute open source ABAP code. They are massive improvements over the status quo, but they aren't very widely installed, and they are not perfect. If SAP wants a healthy ABAP developer community, I'd recommend that SAP join these projects, contribute to them, and make them awesome. Then include (up-to-date) versions of them in the standard Netweaver ABAP distribution.
Speaking of up-to-date, implement ABAP package and dependency management - Maven is kind of a nightmare, but it works. Let's say I want an mock/fake library like MockA (highly recommended) to use in my ABAP Unit tests. I go out and find it on Github, install SAPLink (which doesn't work properly so I have to go back and activate everything), download the .slnk file, install that using SAPLink (which doesn't properly install some interfaces, so I have to reinstall it), and finally I can use it in my project. But I find a bug! So I report that bug to the maintainer, who is awesome and fixes it in less than a day. My reward? I get to do the whole download, install, install all over again. We should just be able to list library versions as dependencies of our packages, classes, and test classes, and the system should handle downloading and installing them. But this will result in organizational chaos, you say. No, it won't. Because everyone will be using namespaces, and those namespaces will be versioned, so we can have more than one version of a library installed and usable at a time.

Right now it's a bit frustrating to switch between ABAP and non-ABAP development. The tooling in the Javascript and Java ecosystems is so far superior and so much more concerned with developer productivity that it begins to be painful to return to ABAP. I can't imagine what it would be like to come to the ABAP ecosystem with no background.

This is a shame, because it's a nice language in a lot of ways, and the business applications that are accessible through ABAP are an absolute goldmine of information and business process execution logic that loads of developers would love to add value to, in the process creating a great deal of value for SAP. If they could only be productive on the platform. I'd love to see SAP take ownership of the developer experience and make the ABAP ecosystem flourish.