What we Need is Standardised Non-OSS Licenses

If you’ve followed the recent (fake) news, you’ve probably already heard it. Oracle is “massively ramping up audits of Java customers it claims are in breach of its licences”

After a quick check on the source (The Register), here’s a more realistic, probably more accurate version of that headline:

Oracle is thinking about auditing 1-2 companies that massively ran the commercial Java extensions in production without paying

There, fixed. Also:

But there is a deeper problem to this discussion

Of course, all sorts of (ex) Red Hat and or Pivotal employees quickly jumped to the conclusion of the kind: Hey this wouldn’t happen with us – the good guys – the OSS guys.

For example:

That’s not surprising, of course. What’s also not surprising is that people who are already strongly opinionated will see their opinions reinforced. Another random example:

If you want more examples, just search Twitter for the article URL. There are tons of reactions.

The latter case is not very interesting. The former, however, is. Aleksey Shipilëv obviously has a good point.

use products with unambiguous licenses, like OSS

… and, of course, he’s not right at all. :) There are some very ambiguous licenses in the OSS field, including many copyleft licenses. Take, for instance, LGPL 2.1, which is a very long license, and contains ridiculuous things like:

If such an object file uses only numerical parameters, data structure layouts and accessors, and small macros and small inline functions (ten lines or less in length), then the use of the object file is unrestricted, regardless of whether it is legally a derivative work. (Executables containing this object code plus portions of the Library will still fall under Section 6.)

(emphasis mine). ten lines of code. What’s a line? Everything between two \n characters? On Windows, does a line have to end in \r\n for this clause to be applicable? What if I remove formatting and have 10000 character lines? Such functions aren’t small, but certainly less than 10 lines. Right? RIGHT?

Hmm…

Not to mention that this single ambiguity (there are more) infects the entire rest of the license text, because it introduces unrestricted use in a rather restrictive library. Think that’s nuts? Go check Hibernate’s license. Most of it (and thus YOUR application, if you patched Hibernate) is affected.

Licensing = restricting

At the end of the day, pretty much every license will restrict rights in some way (except for the public domain “license”). The problem with commercial licenses, however, is that they’re very unique, whereas OSS licenses are usually always the same (mostly some [X]GPL or ASL, MIT, BSD). In other words, OSS licenses are standardised and thus: pretty well understood. And thus: Much less risky.

That’s not the case with commercial licenses. Take the jOOQ license for instance. As of the end of 2016, it’s 23 pages strong (including the annex containing pricing). What does the license mean to our customers? Here’s a TL;DR version (obviously, if in doubt: the actual license will apply, not this TL;DR version):

  • Developer workstations need a timely limited or perpetual license
  • All server workstations are licensed for free, perpetually
  • Object code may be distributed and sublicensed
  • Source code may be used (e.g. for maintenance), but not distributed

And, of course, there are different price plans, but those aren’t really part of the license. So, jOOQ feels like Open Source: source code is shipped, may be used for documentation purpose, may be patched, recompiled, but not distributed, i.e. it isn’t free as in freedom (of course not, it would be the end of our business).

But what does it mean that the source code may be used? The license explicitly allows “modification”, but what does that mean? Are you also allowed to document such modification, just not ship it? E.g. in a public GitHub issue? Such that other users who are affected may profit from your fix?

If in doubt, the best way forward is to ask the vendor. In our case, we’re very open minded and quick to answer – and also quick to improve the license when it is not clear.

In Oracle’s case, a bit less. Of course, because Oracle is a huge company, and who are you even going to ask? Who will take the time to answer an individual question? It’s simply not possible.

The solution: Standardised commercial licenses

There aren’t too many business models with software. First off, there are a few different categories of software, e.g.:

  • SaaS: This is still the wild west. But essentially, you don’t license the software, you rent an access point.
  • Servers: Databases, programming environments, operating systems, they all fall into this category. These are systems that run your software (and/or data).
  • Libraries: Things like jOOQ, Hibernate. These are programs that are embedded in other programs (e.g. SaaS or Servers)
  • Tools: Things like IntelliJ, JRebel. These are programs to create and manipulate data, but they aren’t needed to run it. They can be easily removed.

Each category works entirely differently. For instance, copyleft doesn’t really affect SaaS and tools categories (unless you want to protect your trade secrets, of course), whereas it’s a killer for libraries.

SaaS, libraries and tools are usually per seat licenses, whereas servers are usually per core licenses – i.e. whatever scales better for both the vendor and customer.

This is an extremely simplified overview of commercial licensing, but imagine: What if all vendors in each one of the above categories could just pick a couple of yes/no answers to a standardised set of questions (e.g. what may be distributed? what may be modified? what may be run?), and they could pick only well understood standard wording of these concepts, then everything would be much clearer.

Back to the original Oracle auditing story

In the linked article, Oracle allegedly starts auditing Java users. Because the OracleJDK obviously isn’t “free” (as in freedom), but partially, it is “free” (as in beer) because there are a variety of use-cases where you don’t pay. However, there are some features that are “commercial” (i.e. non-free-as-in-beer), such as JMC and the Flight Recorder.

The interesting thing is that both of these features (and some others) ship with the “free” (as in beer) OracleJDK, but they’re part of the “COMMERCIAL FEATURES” (legal yelling) and those features must even be documented in YOUR LICENSE using this notice, such that YOUR end users may also not use them for free:

Use of the Commercial Features for any commercial or production purpose requires a separate license from Oracle. “Commercial Features” means those features identified Table 1-1 (Commercial Features In Java SE Product Editions) of the Java SE documentation accessible at http://www.oracle.com/technetwork/java/javase/documentation/index.html

(Did you know that? If you’re using OracleJDK in your application, you have to embed the above in your own EULA).

But do note, outside of these cryptic licenses, I’ve found several references to

Java Mission Control is available free of charge for development

E.g. here: http://download.oracle.com/technology/products/missioncontrol/updatesites/base/5.2.0/eclipse

Of course, this has absolutely no legal value, it might have been true at some time but now outdated. But that’s how I remember it. I can use Java Mission Control for free for development (not for productive use). Now, we’re back to this discussion. What’s productive use?

  • Can I profile a simple test program for free? Probably yes.
  • Can I profile my entire program (e.g. jOOQ) for free? Probably yes.
  • Can I run the profile in an CI environment to detect regressions for free? Hmmm.

And how is that understanding of “free” encoded in the actual license?

Standardised wording

Oracle has a long tradition of giving away software for free-as-in-beer to developers. Back in the days (before OSS, when there was only Oracle and IBM), that was a cunning move, because the money is not in development. It’s in operations. So, if developers get top notch software for free, they become evangelists. They’ll love the products, and convince the end users.

But again. Who are developers? When do they stop developing and start operating? When they test? When they ship?

We’ll never know for sure – as every vendor writes their own, unique license.

What we need is a standardised set of well understood commercial licenses, just like the OSS folks have their standardised set of well understood OSS licenses. For our industry as a whole, this would be of immense value, because the little fish (like ourselves), we could compete much better with the big ones without having to give away all of our IP for free under the terms of an OSS license. Our customers would no longer run into any legal issues. All risks from weird license texts would be removed.

And hopefully, this would put pressure on the big ones. And prevent articles like the one from the Register.

With Commercial Licensing, Invest in Innovation, not Protection

When people start creating commercially licensed software (like we did, in 2013 with jOOQ), there is always the big looming question:

What do I do about piracy?

I’ve had numerous discussions with fellow entrepreneurs about this topic, and this fear is omnipresent. There has also been a recent discussion on reddit, titled “prevent sharing of a Java library”. I felt reminded of the early commercial jOOQ days, when I discussed the various options / modalities of the new commercial jOOQ license with the Data Geekery legal counsel – which was clearly the biggest financial investment in early company days.

Build licensing around trust, not fear

One thing that bothered me most about jOOQ’s dual license in its early days is that our paying customers will have less rights than our continued Open Source users. Obviously. If you’re using jOOQ with an Open Source database, you can use the jOOQ Open Source Edition for free under the terms of the very permissive Apache License 2.0. You can do pretty much anything with jOOQ including forking it, rewriting it, creating and distributing a new jOOQ (just don’t name it jOOQ, we own the trademark). The only limitation is: it doesn’t work with commercial databases, but you don’t care about that if you’re using MySQL or PostgreSQL for the next 10 years.

If you’re using jOOQ with a commercial database, however, you need to purchase a jOOQ Professional Edition or jOOQ Enterprise Edition license. Of course, there are costs, but that’s not the problem, because jOOQ is awesome and delivers 50x the value it costs.

The problem is that:

  • Interested developers, architects, etc. now have to go through the hassle of convincing their employer’s legal / purchasing / compliance / … departments and do all sorts of paperwork.
  • Paying customers (at the beginning) could no longer patch jOOQ if they found a bug. They had to wait for us, the vendor, to deliver a fix.

These things were remedied rather quickly in the commercial license text. The commercial jOOQ license now grants access to the commercial source code and allows users to modify jOOQ themselves (of course warranty is then disclaimed), without needing to wait for the vendor to deliver the fix. It is still not allowed to distribute the modification’s source code, although we’re looking into possible legal solutions to allow that as well, such that commercial customers can share patches for commercial parts of jOOQ as well.

In other words: We want our commercial customers feel as if jOOQ were Open Source for their every day job.

Isn’t that crazy?

So, people get the entire source code and can build jOOQ. Aren’t we afraid that our commercial, “cracked” jOOQ distributions wind up on warez sites? Of course we are. And it happens. And we’re maintaining a list of companies that “obviously” don’t comply with our terms (e.g. they’ve been using the free trial in production for 2 years). But they’re only very few. And even if they weren’t few, should we introduce tracking logic in jOOQ to check if customers / trial users are compliant? Should we collect IP addresses? User E-Mails? Count workstations? Shut down jOOQ, if non compliant? Shut it down where, on production servers, perhaps?

The truth is, most companies are honest. We’ve had many customers frequently upgrade their contracts. E.g. every couple of months, they’ve purchased new licenses. We’ve had other customers reduce their contracts. The team started with 5 licenses and now consists only of 1 person doing maintenance work. We’ve had customers not touching their contracts, using jOOQ with e.g. 10 licenses for a long time. Some of these are overlicensed, yes. Some of these are underlicensed. It happens. It’s not good, but it’s also not the end of the world. We’re in constant touch with them to see if their license count is still up to date. In the end, we trust them. They trust us.

The worst thing we could do now is introduce some sort of license checker that might be buggy and accidentally shuts down our honest customers’ production system! For the slight chance that we might be catching someone who “cracked” our software (and who probably manages to “crack” also our license checker anyway).

Even if we’re not shutting down the software but logging messages somewhere, the end user (our customers’ customer) might get a very weird feeling when they see it. We would be indirectly damaging our customers’ reputation for what was probably just an oversight. Or, again, a bug in our license checker.

Is that really worth the trouble? No way!

(an exception is the free trial version, which must be deleted after one month)

Different types of software

The problem is: There are different types of software. Essentially, there are:

  • Tools
  • Libraries
  • Servers
  • SaaS

The difference is:

  • Tools run on premise but are independent of the end user application. The customer doesn’t depend on the tool.
    For instance: IntelliJ IDEA
  • Libraries run on premise and are embedded in the end user application. The customer completely depends on the library.
    For instance: jOOQ
  • Servers run on premise and are linked to the end user application but run independently. The customer can often replace the server, but cannot “open” it. It’s a black box.
    For instance: Oracle Database
  • SaaS runs in the cloud and is completely independent of the end user application. The customer cannot influence it in any way.
    For instance: Salesforce.com

As you can see, tools are “not critical” for the customer (being “just” UIs giving access to “the real system”), and while servers and SaaS are critical, all three of them run independently. It is easy for a vendor to implement license checkers inside of those because they’re in control of running the software. With libraries, it’s different. You cannot make any assumptions about how your library is “run”. Is it part of a single JVM? Or multiple JVMs? Run for a couple of seconds only, or for a long time? Used frequently or only very rarely? Is it allowed to spawn its own threads, collect its own data?

Too many open questions.

Long story short: Invest in innovation, not protection

Unless protection is really important in your area because you’re using extremely complex algorithms that no one should know about, then you shouldn’t worry about piracy too much from a technical perspective. In our case, jOOQ isn’t super secret. Anyone can build their own jOOQ, and there are many (much simpler) competitor frameworks. Our business is maintaining by far the best Java SQL DSL and apparently, no one else wants to compete with us in this niche, so why be afraid of theft.

If protection is important, well then run a SaaS, because then you don’t need to ship any software. For instance: Google, one of the biggest SaaS vendors out there, doesn’t share its search engine algorithms with you.

Once you stop worrying about who is going to steal from you, you can start investing all that time in awesome new features and quality to make those loyal and honest customers happy who happily pay for your software. And who knows. Perhaps some of your “pirate customers” will eventually switch jobs and work for someone who takes compliance more seriously. They have been happy “customers” too, and will also recommend your software to their new peers.

The 5 Golden Rules of Giving Awesome Customer Support

This is usually a tech blog, but every now and then, we make an exception when there’s something important to say.

Today, I’m going to criticise a lot of our industry’s understanding of support.

Who is this article for?

It’s for every software engineer giving support to users and/or customers, and every manager who works with software engineers. In fact, it isn’t restricted to software, but since this is a Java blog, let’s pretend it is only about software.

#1: All users are customers

While we’re at it, let’s use the terms “users” and “customers” as synonyms, because every user should be treated like a paying customer. In fact, every user should be treated like the only paying customer you have, on which your whole business depends. This is why I will put “customer” in quotes in this article.

This is something you should constantly remind yourself of. It doesn’t matter if your “customer” paid you millions for your software, or if they just use your quick and dirty Open Source library that you implemented in your free time.

Why is that? Because it’s your fault and problem as a vendor if you chose some business model (or if you don’t even have a business model) that generates (excessive?) support work. Change the model. Make more non-paying “customers” pay for support. Help them understand the value they’re getting from being your paying customers. Or keep doing stuff for free, it doesn’t matter as long as you will remember that it’s your problem, not theirs.

Always take Apple as a shining example. Apple customers love to pay excessive amounts for average hardware and software with nice-looking design. This has nothing to do with support, it just shows that Apple has gotten making customers pay right. Because Apple users want to be paying customers.

#2: Your customer took the time

Remember this:

Your “customer” took the time to report an issue.

Period. That’s all there is to say. When a “customer” gets in touch with you, they took the time to get in touch. So you should be thankful they took the time. Not all “customers” take the time. Most of them just rant and leave you silently if something goes wrong. Or worse, they rant in public and then leave you.

If a “customer” does take the time, this means they stand for thousands of others who don’t take the time but like your product and want to continue liking it. Don’t spoil that. Keep those customers!

#3: Your customer is abrasive and demanding

The food chain goes this way round. Accept that. Moreover, remember: You’re not some divine entity that grants an audience to an unworthy soul who should kneel before thy wisdom. You’re the supplier. They’re the customer. They’re the king. You’re the servant.

Of course they are abrasive and demanding. They are the “customer”. They had a bad day. They have an idiot boss. Their job sucks. They work on legacy code. They blame you (and everyone else). It’s not their fault. It never was.

So what? That happens from time to time. More often than not, however, “customers” are nice people, and again: They took the time to get in touch.

So, your job is to thank them for that. To make sure you do everything needed to help them. To solve their trouble and issues. Which often isn’t what they’re saying. They just want you to listen. A workaround might just be enough. They’ll understand you can’t fix things immediately. But do help them.

#4: Your customer doesn’t understand your product

You’ve spent all that time with your product. You know exactly how it works. You have accepted all the caveats. The bugs. The workarounds.

Your customer doesn’t. They have more important things to do than reverse engineer your funky product. If they don’t understand something, always assume it’s your fault. You could improve the product. Or the documentation. Or your SEO to make sure they will find the documentation. Or your support channels (see below). Whatever. Always assume that your “customer” doesn’t have the time to really understand your product. Why should they.

Learn from your “customers”. Their misunderstanding of your ways is your chance to do it better. Every single time.

#5: Your customer doesn’t care about your workflows

And here’s the one thing you must never, NEVER do:

NEVER tell your “customer” that they’ve used the wrong support channel

NEVER do the above. They’ll learn by themselves after a while. Or they don’t. Does it matter? It doesn’t. They’ve taken the time to reach out and that ought to be enough.

Perhaps, you’ve chosen a confusing setup of support channels. Or complicated products (looking at you, Bugzilla). Improve it, then. Make it easier for your “customers” to choose the right support channel if they have gotten it “wrong”.

What does wrong support channel even mean? Wrong support channels create administrative work to you. You have to copy a bug report from Google Groups to JIRA. From your E-Mail program to GitHub. Etc.

So, a “customer” has reported a bug on the discussion group. You prefer they create an issue in an issue tracker. How do you react?

  • Bad: This is a bug not a discussion, we have a bug tracker for this. Can you please create an issue??!?
  • Good: Thank you very much for bringing this to our attention. I have registered an issue #717863 for this problem. We’re looking into this as quickly as possible and let you know about our progress. If there’s anything … blah blah.

As simple as that.

Conclusion

There are many more things that help you get support right. And it isn’t always easy. Sometimes, it’s just too hard to get it right. We all have tons of things to do. And priorities.

But remember one thing. This is (almost) never the “customer”‘s fault. And even if it is, you should never make them feel as if it were. There are enough enterprise-y companies out there whose processes are too complex and heavy to ever give awesome support.

Don’t be like those companies. Be awesome for your “customers”.

The Caveats of Dual-Licensing

We’ve been in business for more than one year now with our dual-licensing strategy for jOOQ. While this strategy has worked very well for us, it has also been a bit of a challenge for some of our customers. Today, we’re going to show you what caveats of dual-licensing we’ve run into.

Our dual-licensing strategy

For those of you not acquainted with our license model, just a brief reminder to get you into the subject. We mainly consider ourselves as a vendor of Open Source software. However, contrary to a variety of other companies like Gradleware or Red Hat, we don’t want to build our business model on support, which is a much tougher business than licensing. Why?

  • Support contracts need a lot more long-term trust by customers, and more outbound sales. There’s only little inbound interest for such contracts, as people don’t acquire support until they need it.
  • Vendor-supplied support competes with third-party support (as provided by UWS, for instance), which we want to actively encourage. We’d love to generate business for an entirely new market, not compete with our allies.

So we were looking for a solution involving commercial licensing. We wanted to keep an Open Source version of our product because:

  • We’ll get traction with Open Source licensing much much more quickly than with commercial licensing
  • While Open Source is a very tough competitor for vendors, it is also a great enabler for consumers. For instance, we’re using Java, Eclipse, H2, and much more. Great software for free!

It wouldn’t be honest to say that we truly believe in “free as in freedom” (libre), but we certainly believe in “free as in beer” (gratis) – because, who doesn’t. So, one very simple solution to meet the above goals was to offer jOOQ as Open Source with Open Source databases, and to offer jOOQ under a commercial license with commercial databases.

The Caveat

This was generally well received with our user base as a credible and viable dual-licensing model. But there were also caveats. All of a sudden, we didn’t have access to these distribution channels any more:

  • Maven Central
  • GitHub

… and our paying customers didn’t have access to these very useful OSS rights any more:

  • Source Code
  • Modifications

Solution 1 – Ship Source Code

Well, we actually ship our source code with the commercial binaries. At first, this was done merely for documentation purposes.

Regardless of the actual license constraints, when you’re in trouble, e.g. when your productive system is down and you have to urgently fix a bug, doesn’t it just suck if you don’t have access to the source code of third-party dependencies? You will just have to guess what it does. Or illegally de-compile it.

We don’t want to be that company. We trust our customers to deal responsibly with our source code.

Solution 2 – Allow Modifications

Our commercial licenses come in two flavours: Yearly and Perpetual. We quickly realised that some of our customers do not want to be dependent on us as a vendor. Perpetual licenses obviously help making customers more independent. But the disadvantage of perpetual licenses is the fact that vendors will not support old versions forever, and customers won’t have the right to upgrade to the next major release. While they are probably fine with not having access to new features, they would still like to receive an occasional bugfix.

The solution we’ve come to adopt is a very pragmatic one: Customers already have the source code (see above), so why not allow customers to also apply urgent fixes themselves? Obviously, such modifications will void the warranty offered by us, but if you buy jOOQ today and 5 years down the line, you discover a very subtle bug in what will then be an unsupported version of jOOQ… don’t you just want to fix it?

Conclusion

Dual-licensing is a tricky business. You partition your user-base into two:

  • The paying / premium customers
  • The “freemium” customers

By all means, you must prevent your premium customers from being at a disadvantage compared to your “freemium” customers. There are certain rights that are probably OK to remove (such as the right of free distribution). But there are rights that are just annoying not to have. And those rights are the rights that matter the most to the every day work of an engineer:

To fix that bloody bug :-)

We’re very curious: What are your opinions towards dual-licensing?

The “Free”, “Standard”, “Open” Software Heresy

There are those people that have a strong, dogmatic belief in what they call “Free” or “Standard” or “Open” software. One of those individuals is Jimmie (let’s call him Jimmie in this article) who has responded to an article about Java persistence by Marco Behler on TheServerSide.

Let me cite Jimmie’s response here:

JPA is difficult but complete. It has a learning curve, and you’ll have surprises if you try to shortcut its complexities. But they mostly are there for a reason. Difficult stuff is difficult using JPA, that’s true.

JOOQ is quick to learn. And is proprietary stuff. Not free. Only one implementation. No public review, only one body involved in its evolution. SQL-oriented, not OO (ok, they say it’s a feature).
As a serious professional, learn JPA. Fully. There is no excuse for not knowing which sql queries are generated in your production app. Replacing it with a more basic framework is no solution.

Let’s not go deeply into the concrete difference between JPA and jOOQ / SQL. That topic has been discussed already in lengths on Reddit. Let’s consider the essence of the comparison as perceived by Jimmie. Because, Jimmie would probably say exactly the same thing when comparing

  • JSF with Ext.JS or ZK
  • PostgreSQL with Oracle
  • MS Office or Google Docs (probably OK cause “gratis”) with LibreOffice
  • Linux with Windows or MacOSX (although he might perform some doublethink as a Mac user)

Software not being free

Jimmie, Is YOUR software free and “not proprietary”? If so, how do you finance it? How do you earn a living? And why are you doing it? What really motivates you? What really motivates your customers and why?

Only one implementation

How many people actually do use alternatives to Hibernate and why? Are they using EclipseLink mainly because they used to use TopLink for the last 20 years and the learning curve (or benefit) to switch to Hibernate is too high? How often do you actually switch implementations? What keeps you from implementing the jOOQ API, and open-source its implementation?

And most importantly: Do you always adhere to the JPA API, even if Hibernate has lots of awesome, proprietary extensions that just happen to work so much better / easier?

No public review

Who exactly is “public”, and what are their main interests? Did you know that one of the major driving force for the JDK is Credit Suisse, being a large customer for Oracle in the Java environment, for instance? What is your stake and relation with Credit Suisse as your “public” representative?

Only one body involved in its evolution

Do you say that to YOUR customers also, about your own software as well?

SQL-oriented vs “a serious professional”

What’s not serious about SQL? In fact, SQL is reviewed by more entities than the JLS, let alone the JPA specs. Have you ever thought about that?

More basic

Fair enough. But don’t forget: You probably replaced your sophisticated EJB 2.0 framework (still a standard!) from the early 2000’s by a more basic one, which was (at the time) proprietary, had only one implementation, had no public review, nor multiple bodies involved in its evolution. It was, at the time, called Hibernate. And let me take the opportunity to cite Gavin King (creator of Hibernate) about when to use Hibernate:

gavin-king-on-hibernate

My reply to you, Jimmie

According to you, JPA has to be learned fully. So I challenge you to also FULLY learn SQL, including all the SQL:2011 clauses, including

  • window functions
  • grouping sets
  • common table expressions
  • distinct/match/type/submultiset/unique predicates
  • time periods
  • partitioned outer joins
  • lateral joins
  • standard OFFSET pagination
  • contextually typed value specifications
  • quantified comparison predicates

… and of course all the details of interoperation between SQL and XQuery, one of the most popular aspects of the SQL:2011 standard!

And please, learn this FULLY, regardless of whether these things are part of your specific implementation. Because as a serious professional, you shall fully learn SQL. And while you’re at that, learn also everything about execution plans, and join, fetch, buffer caching, cursor caching and all other sorts of algorithms. Because there is no excuse for not knowing which SQL transformations are generated by your database’s CBO.

I know you like standards, Jimmie. But beware of the fact that there are some people out there who cannot wait for a standard to evolve to solve their problems. They may have more immediate problems. More specific problems. Simpler problems. Problems that might be solved only by proprietary software, so far. Or problems that are solved by proprietary software, that can be put into production with much less effort than your standards, Jimmie.

Lower time-to-market is what your customer might consider “professional”. Not whether this or that tech is used.

Someone always invents something proprietary at some time. It might just evolve into a standard. It might have been a bad idea and not evolve into anything. Or it might evolve into a standard and then be the worst standard ever. See again: EJB 2.0. I think we all agree on that, today.

No, Jimmie, the world isn’t black and white. It isn’t just about standards vs. proprietary. About free (libre) vs. commercial. About free (gratis) vs. “closed”. It’s about creating value for your customer.

Oh, and Jimmie. I sincerely hope you’re neither a Windows, nor a Mac user, because that wouldn’t be free, and there is only one implementation of each OS, and no public review, and only one body involved in their evolutions. And yet, the whole world runs on one of them.

Thanks for your attention, Jimmie.

What if Developing a Simple Data Management Application Just Took 1-2 Days?

What if developing an application just took 1-2 days?
What if I can create it myself with only 10 clicks?
What if I don’t need you developers anymore?

Said every manager since the beginning of history. This is what all managers dream of. Click click click, next next next, and you’re done! Easy, right? Time-to-market: Zero.

Of course, we engineers tend to sincerely doubt that this is possible

Data transformation and navigation

Let’s have a look at some tech stuff.

ergonAs a personal passion, I have always loved the idea of non-procedural approaches to manipulating data (e.g. SQL or XSLT). One of the best pieces of software I’ve ever seen to manipulate data was used by Ergon, a previous employer of mine and a customer of Data Geekery who has created a tool called JTT – Java Table Tool, a dinosaur written around 15 years ago. It was essentially a live RDBMS schema and data navigation tool written as a Swing desktop application. With only little metadata, this application was then capable of providing overviews of:

  • All the tables that you as a user had access to
  • When clicking on a table, you got an editable list of all the records in that table with standard filtering and grouping options
  • When double-clicking on a record, you got an editable popup with details
  • When clicking on a record, you got a “children” view with tabs for all foreign keys that link to this table. Obviuosly, the tabs were again filled with records, which could be navigated through the same way as the “parent” records
  • Foreign key values were not displayed using technical IDs, but using relevant data from the linked record

… and much much more. All business logic and complex update rules were implemented using triggers and grants and just a little meta data to decide what information is primary and what information is secondary (or hidden). Most of the views obviously also were exportable to CSV, XLS, or PDF.

Ergon used this wonderful JTT for internal purposes only, e.g. for accounting, invoice management, as a CRM, as an HR tool. It pretty much ran the company and it did its job very very well. It was one of the technically most awesome products that I’ve ever seen. So lean, so simple, and so powerful (albeit, the UI… Oh well, Swing).

I pressed the product manager and the sales managers to consider revitalising this gem and to make a webapp from it that can be sold to other software companies as a product. At the time, something like Eclipse RAP might have been a good choice to allow for a hybrid desktop and web UI.

Unfortunately, they never wanted to make a proper product from this tool. So, I have always thought that at some point, I’ll create my own JTT, I’ll sell it and I’ll get rich. A browser-based database schema and data navigation tool that allows you to set up a basic data management software product in virtually 2-3 days, even when running on large schemas.

Too late, it already exists!

So these were our plans. And then I read this InfoQ article (and later on, also this DZone article by Val Huber, the same author).

“Unfortunately,” for me and for Data Geekery, I have come to discover Espresso Logic’s Live Browser, which does exactly that. Ironically, I have already blogged about an Espresso Logic product before, when I had spotted their pretty cool reactive REST API (where here, reactive means that with a simple rule engine, you could model all sorts of Excel-spreadsheet-like data updates).

But this Live Browser indeed tops what I had in mind from my JTT experience. It is actually built on top of the aforementioned reactive REST API, so it inherits all the nice features, such as the “role-based, row/column level read and update permissions”, the reactive programming features, etc. Here’s an example view from their product announcement website:

Another example from the InfoQ article:

As you can see, pretty much all of the JTT features that I’ve mentioned before are available out of the box:

  • Table selection
  • Filtering
  • Detail views
  • Foreign key navigation
  • Child navigation
  • Data manipulation

(Ergon, if you’re reading this: You see? I told you :-) )

Consider having this as a general-purpose database inspection tool in your company. As a developer, you can quickly navigate the schema (and the data!) in a way that you will never find in Toad or SQL Developer. Obviuosly, the tools don’t compete, as SQL Developer is a database development tool, whereas Live Browser is more of an actual… well, a live data browser.

This browser could also be used as a prototyping engine to assess whether your database schema really models the business case of your customer – a quick display to verify the requirements. Well, as I said, it is a general purpose data browser, that can be used for virtually any simple use-case.

espresso-companyNow, I have again signed up for a free trial at Espresso Logic, to try Live Browser myself. I could log into Logic Designer immediately (as described in my previous article). Do note that there is no single-sign-on in place between the Logic Designer and the Live Browser, so I needed to reuse my credentials to log in also to the browser.

Once I’ve logged in, I could really play around with the data in an easy and straightforward way. All the server-side rules that calculate totals are working as well. E.g. I tried changing the price for a product inside a PurchaseOrder (i.e. inside a LineItem), and it updated the PurchaseOrder’s “Amount Total” value automatically.

I wish I had created this product three years ago when SaaS started getting big. Now, I guess, it’s too late… Congrats, Espresso Logic!

More information

For more info, read Val’s article on DZone

Modern Shareholder Value Hopes

So, everyone is discussing the $19B Facebook / Whatsapp deal, discussing it on every media. And Zuck says it was actually a bargain.

Yeah right. A bargain. Read CNN’s 10 other things Facebook could have bought with $19 billion.

We at Data Geekery are more down to earth, selling actual value to our own customers. So we take the opportunity to issue this friendly reminder about what happens when you and your shareholders believe that a primitive chat service is worth $19B because of its oh-so-many users:

So, should our own business not work out, we can still make tons of money this year through PUT warrants on FB. Because the above is not the only issue with Facebook. Check out this video: