Open-ness and uncertainty

We, as a company, migrated to SAP MaxDB back in 2005 after finally dumping an old installation of MS SQL Server 97 on top of MS Windows NT 4.0 in favor of, well, an SAP MaxDB 7.5 installation on top of a Debian GNU/Linux operating system. Reasons for this decision:

• Comparing initial installation, configuration and maintaineance effort, we had to figure out that in many respects SAP MaxDB was the most simple RDBMS we could get our hands on: Straightforward installation, deployment, backup, migration, a set of rather well thought-out, well-working tools, extensive documentation and a friendly user group – what else would you expect?
• Of course, compared to Oracle 9i or a more up-to-date MSSQL, these days SAP MaxDB simply was an affordable solution, given then and now it was provided free-of-charge for use along with open-source and/or non-SAP technology.
• Wearing the label SAP, we thought that eventually there might be some way of getting “high-value” support by SAP on that given we offer some sort of MaxDB use case that justifies doing so without being into any other SAP technologies / products (as so far we simply haven’t found one in there to suit our use cases).

Getting into MaxDB, we quickly came to a rather stable and reliable environment. Subsequently, we spent a couple of money to have the manufacturer of our “old” system infrastructure to add support for MaxDB to their product for our specific environment. And we’ve been working on top of a heterogenous system built on top of SAP MaxDB for a couple of years, evaluating to buy professional support and licensing right from mySQL AB (who, by then, did offer SAP MaxDB along with mySQL as a “professional, enterprise-grade RDBMS”), until eventually: “MaxDB back under the SAP roof!” So no more licensing by mySQL AB, and a little later, there also happened to be a change in licensing, basically coming down to a construction like this, as far as I understand it:

• SAP customers to get professional, paid support for SAP MaxDB used along with any other SAP applications according to a given licensing model.
• SAP customers using SAP MaxDB along with non-SAP applications may order some sort of support contract addition to their SAP software contract specially made up for this kind of purpose.
• Non-SAP customers may use SAP MaxDB for free according to the terms of the Community License. No commercial support offerings are available to those it seems.

More uncertainty
In the end, after the licensing scheme (proprietary -> GPL/proprietary dual-licensing -> “proprietary community license”) has changed a couple of times and, now, an extensive FAQ collection outlining that the core strategy of SAP obviously is making MaxDB more suitable, more well-integrated, more “usable” along with other SAP applications (which is an obvious thing to do, no doubt about that), we are evaluating migrating our database backend to a recent Oracle release altogether. Why?

Even while we tried so, we failed managing to become an SAP customer with SAP MaxDB being the only SAP product we use. So, looking at our relation to SAP, we always will end up being the “community user” using something we get free-of-charge in an environment unknown to SAP.

Consequently, as we do not use any other SAP applications, I don’t really see where things are heading in near future. Where will SAP MaxDB development go? Could it be that, eventually, one day the “community license” will be terminated as well, making SAP MaxDB (and patches/updates) completely unavailable to anyone outside SAP again? Could it be that, in course of making the database more suitable for use with other SAP applications, one day it simply won’t be a feasible solution for our environment anymore as, this way, it is obviously not aiming at being a “general purpose RDBMS” anymore? In the past, it seems a lot of features we thought of as being pretty interesting (WebDAV/WebSQL, Synchronization tools) have either been removed altogether or aren’t maintained anymore – can we be sure this is not eventually, one day, to hit some other part of database administration tooling?

There used to be an Open MaxDB Group a while ago which, it seems, has quietly come to a halt. This makes me think that, for a “community license” user, there is next to no way of having ones interests related to MaxDB tooling, development, stragety, … represented to and eventually being recognized by SAP. Looking back at some discussions in the (kind and very helpful) MaxDB users forum, I once read a message outlining SAP not wanting to be a “general purpose DBMS seller”, which surely seems true here. But given in our situation a “general purpose DBMS” is right what we want / need, maybe SAP MaxDB is not the right strategy anymore, at least at the moment…

… and this is where, somehow, I’ll get back to the initial thoughts on open-ness and open source: In my opinion, the current state of “MaxDB open-ness” is, rudely speaking, next to useless to most customers not using SAP applications but looking for a long-term RDMBS strategy as there simply seem too many questions relating to development, long-term availability of updates, … unanswered. Having a “commercial database license” option provided by SAP would help easing these problems. If this is not possible / unwanted, having an “open-source” MaxDB at hand, along with support by external providers (so far we get MaxDB support by infolytics AG which is pretty good) would ease the pain of strategy uncertainties. Maybe the “new open-ness”(?) at SAP might change this thing for the better, somehow – I still hope for this as SAP MaxDB, after all, still is a really good database platform and really fun working with…

Assumptions regarding community documentation…

Initially, as one might expect reading the name, “NetBeans Community Docs” was a project initiated to collect any documentation (articles, FAQs, tutorials, …) provided by NetBeans users for the sake of helping other users. This, and I still and firmly believe so, is a good idea from various points of view:

• First and foremost, it is an easy way for everyone to contribute back to an open source project without being a developer or “code hacker”.
• Then, of course, documentation provided by those who build a tool is rather different to documentation provided by those who use a tool; from that point of view the “community documentation” approach seems sane regarding the idea of gaining “user” documentation of actual use to someone as it addresses the way a potential user would see a given problem (both in terms of content and of style of documentation – thinking of “learning trail” vs. “short, to-the-point” articles).
• Last but definitely not least: Community contributed documentation, to developers and “tool makers”, seems a good thing as it exposes how end users do think and work, thus it eventually might help making a given tool better by having a better understanding for end users needs and wishes.

… and voluntary contributors in special.

Of course, community documentation doesn’t come “from out of nowhere” but has to be written by some actual contributor. And a contributor is likely to, well, contribute documentation in a given way which I quickly want to outline using an example rather familiar to me: Myself. I started using NetBeans earlier because I was searching for a quick, “intuitive”, usable IDE to do server sided / web Java development using maven2. Eclipse maven2 tooling sucked at this time (at the very least), and NetBeans came in rather handy here. In course of adopting the tool, I read some documentation, tried out a lot of things, and eventually wrote a bunch of articles on issues I stumbled across during this process… and time passed, with a few things happening:

• Generally, the IDE saw some more releases along the way, each one a little better regarding technologies I am working with, each one requiring a little less “additional” documentation than its predecessor.
• Same way, I somehow “consolidated” in my everyday work using the IDE, I finally got it working as an unobtrusive, highly productive tool not coming into my way anymore (mostly at least). The situations in which to really “hit a wall”, assuming a given solution to be worth writing an article or even a short tutorial about, are becoming less and less frequent and eventually disappear.
• And, last but not least, a bunch of things addressed in (community) documentation articles earlier by now either are addressed by the IDE itself (which has changed in some aspects to indeed be what it should be – an intuitive tool) or by “official” NetBeans documentation or it simply is “not an issue” anymore in everyday work, which makes it rather likely that community contributors won’t bother updating any “old” contributions as soon as it is not an issue to them anymore.

So, assumptions from that are that, having a “limited” set of contributors, it is rather likely to see the amount of new contributions reduce to somewhere next to Zero sooner or later, which actually might be good (as it is an expression that, overally, the tool has become convenient enough to most end-users and it allows end-users to simply and productively get their work done without bothering too much about the tool), but then again is a problem for the “community documentation” approach itself (which, as stated above, is generally a good thing).

Conclusions and ideas

How to deal with such a situation? How to resolve the problems outlined above without completely ending the project altogether? As stated, I just have a couple of vague ideas…:

• Attracting more users is an essential and important approach. Given the above assumption that “contributors” are likely to become less active as soon as they are perfectly happy working with the tool, a continuous stream of “new volunteers” addressing new areas of technology, providing new needs and wishes regarding working with the IDE or “just” running into problems no one has seen so far (because no one so far tried) seems the way to go. Is anyone using NetBeans along with, say, Python or PHP or Scala or Groovy in a production environment, or making use of its JavaFX tooling? So far, there are obviously few people on the community docs team dealing with these aspects enough to write “real-world” documentation (i.e. doing “productive everyday work” using the IDE).
• Making things more “responsive”, interactive. As soon as contributors are ready to write documentation on their own – fine. But after all, some day it might be difficult to contributors to figure out whether an issue they just stumbled across is actually worth documenting or “just” something every other user would immediately figure out taking a closer look. Maybe, from this point of view, the project itself should grow to not just be “contributor-driven” but more than that “user-driven”, allowing end-users to better state which documentation formats they like (which is surely likely to differ – i.e. /myself prefers short, to-the-point written articles on given topics and strongly dislikes screencasts and/or long, time-consuming “learning trails”) and on what issues / topics / aspects they would like to see documentation on. Maybe this also would be the way to deal with updates – a contribution being reviewed by its original contributor or someone else who is qualified enough to do so only on user demand.
• “Linking” the world together better. Using a wiki, a dedicated blog or whatever centralized structure for keeping community contributed documentation is a good idea to some extent, but then again: Isn’t a single blog entry written by someone somewhere around the world also “community contributed documentation”? Maybe taking more care of these contributions (and/or encouraging people to contribute this way) would be a way of addressing those who aren’t part of the “documentation-writing community” at the moment…

However I still think there’s quite a lot of questions unanswered, and, at this point, I see that these questions would be addressed and eventually answered best by those using NetBeans community docs… so, what are your thoughts on that? Have you ever read a NBCD article? Have you even contributed one? How did you like the project, the documentation structure, …, if you did? Share your thoughts…