jOOQ Newsletter: January 21, 2015 – Groovy and Open Source – jOOQ and the strong Swiss Franc

Subscribe to this newsletter here

Tweet of the Day

Today, we’re very happy to have “spied” on our users as we can now show you a whole Tweet Conversation of the Day

RxJooq, or reactive jOOQ. How does that sound!? Yes, jOOQ is growing to become a hype among SQL and fluent API aficionados. A recent discussion on reddit already puts jOOQ on the same level with Hibernate with more than 10 mentions in answers to the question “Java: What ORM to use”. Our goal has always been for a Java developer to ask themselves at the beginning of a project:

Is this a jOOQ project, or is this a Hibernate project (or both)?

It is too early to announce anything, but at Data Geekery, we’re very interested and thus putting efforts into collaborating with Red Hat to make the jOOQ / Hibernate integration work more seamlessly, so stay tuned for more goodness in that area.

Groovy and Open Source – What it means for us

You may have heard of Pivotal’s recent announcement about their withdrawing sponsorship from the Groovy and Grails ecosystem. This isn’t exactly a surprise to many people as Pivotal’s main focus has shifted towards their PaaS business quite some time ago. The interesting aspect from our perspective is the fact that a whole ecosystem seems to have relied on the benevolence of a single sponsor. Quite a risk!

We think that Open Source should work differently. Open Source is a fine means of offering freemium and (legally) riskless software to potential customers in order to help customers start engaging with a brand. The ultimate vendor goal with Open Source is always upselling. As our valued jOOQ users and jOOQ newsletter and blog readers, we obviously hope that you will eventually understand all the combined SQL value put into jOOQ, and thus upgrade to a commercial jOOQ subscription.

This wasn’t necessarily the case at Pivotal. There is no obvious path from using Groovy (or Grails) to buying Pivotal’s cloud platform solutions. To make things worse, in order to survive, the Groovy platform now depends on a new, arbitrary sponsor whose incentive to sponsor Groovy might be 100% different from Pivotal’s. For the end user, this will not be the same Groovy any more – so it is hard to believe that Groovy will not suffer heavily from any future transition.

We believe that vendors shouldn’t depend on benevolence. We believe that vendors should have a very clear strategy why they’re creating a product, and do everything necessary to satisfy real customer’s needs. So we want to take the opportunity and thank you for being with us, and for making jOOQ (both the Open Source Edition and the Commercial Editions) what it is: A platform valued by both users of Open Source and commercial databases.

More information about our take on Pivotal and Groovy can be found on our blog:

It’s jOONuary! Profit from our 20% Discount Promotion

Speaking of our customers, there has never been a better time to become one!

Your budget for 2015 has been set in stone? You spent too much money on geeky infrastructure during the Holiday Season? Not a problem for your planned jOOQ integration! If you purchase new jOOQ licenses in jOONuary (January 2015), we will offer you a limited-time 20% discount on all price plans. Act quickly!

http://www.jooq.org/joonuary

jOOQ and the Strong Swiss Franc

We’re a Switzerland-based company, and as such are heavily influenced by recent events on the currency exchange markets. The EUR (which is our sale currency) has plummeted almost 20% compared to the CHF (which is our accounting currency).

This affects all of the Swiss export industry, and many companies are starting to take measures. We will not take any measures thus far and continue with our existing EUR-based price model. For our international customers, nothing will change. For our Swiss customers, this means that in addition to the above jOONuary discount, you will now also benefit from a “Euro discount”! Did we say there has never been a better time to become our customer?

jOOQ 3.6 Outlook

The upcoming jOOQ 3.6 will not be less exciting than the previous versions in the least bit. Here is a quick outline of what we’re going to be doing in the upcoming release:

  • SAP HANA support. We’ve been talking to database vendors in the past, and we continue to do so, maintaining good relationships with the technical and community people at the vendor side. This time, the collaboration initiative came from the vendor directly, and we’ve heard them.

    SAP HANA is an emerging cloud SQL and in-memory SQL platform, with a big Java and Scala based tool chain, which constitutes a perfect match for the jOOQ ecosystem. We’re going to support both HANA’s SQL features as well as HANA’s SQLScript features in the jOOQ 3.6 Enterprise Edition. If you’re an SAP HANA user and interested in details, or in a free preview of jOOQ 3.6.0, please contact sales right away. We’re more than happy to provide you with more info.

  • Nested records and tables. One of the SQL standard’s most underestimated features is the capability of nesting records and tables. In a true ORDBMS, tables (or MULTISETs) can be nested any level deep. If your SQL database supports these features, it is very easy to materialise a nested object graph directly in the database, instead of relying on the JOIN-based workarounds provided by modern ORMs.

    Nesting of records can also be very useful when reusing common data structures, such as audit columns (creation_date, creation_user, modification_date, modification_user). JPA supports the @Embedded annotation for this, and we’ll delve into these features as well.

    We believe that true MULTISET support will obsolete our competing products’ most important asset: mapping. Once you can declare all mapping already in SQL, you will no longer miss JPA once you’ve migrated to jOOQ.

  • A new ConverterProvider SPI. Converters are great for supporting custom data types, but having to register them all the time is tedious. What if jOOQ just supported T <-> U conversion right out of the box, for any combination of T and U? We’ll let you register all your favourite converters and jOOQ figures out the conversion path through the converter graph.
  • Even better PL/SQL support. PL/SQL types are ubiquitous, but they are not easily accessible via JDBC, and thus via jOOQ. We’re researching a variety of possibilities of working around JDBC’s limitations to allow you to use your favourite PL/SQL types: BOOLEAN, RECORD types, perhaps even table types.

 

Upcoming jOOQ Events

Have you missed one of our talks and presentations in the recent past? No problem at all, we’re back on the road after a short winter break. Here are all of our upcoming events:

Keep up to date with our own and third-party jOOQ events on our news website:http://www.jooq.org/news.

We’re looking forward to meeting you and to talking about all things Java and SQL!

Suis-je Groovy? No! What Pivotal’s Decision Means for Open Source Software

Today there was great news in the JVM ecosystem.

Pivotal, the company who is committed to OSS has become a bit less committed:

committed

The reaction in the community were largely summarised by the hashtag #jesuisgroovy:

The interesting part in Pivotal’s announcement is this one:

The decision to conclude its sponsorship of Groovy and Grails is part of Pivotal’s larger strategy to concentrate resources on accelerating both commercial and open source projects that support its growing traction in Platform-as-a-Service, Data, and Agile development. Pivotal has determined that the time is right to let further development of Groovy and Grails be led by other interested parties in the open source community who can best serve the goals of those projects.

The official announcement can be read here.

Groovy is not a viable business (for Pivotal)

In other words, Groovy is not a viable business for Pivotal. And it’s hard to disagree here. Groovy has never been created with any commercial interests. Like many Open Source projects, Groovy was created in order to make something “better”, mostly for the sake of it being better. Of course it was useful as it introduced a lot of nice features into the Java ecosystem at a time before all these new JVM languages popped up. And before all these new JVM languages finally had an effect on Java-the-language itself.

On the other hand, the Groovy website’s rather geeky look-and-feel has never made it seem as though virtually anyone had any commercial interests in the language or the platform for that matter. I’m not trying to be harsh here, Groovy is an awesome language, created with love. But maintaining an Open Source ecosystem is hard work. It costs a lot of money and effort. And in the case of Groovy, it is just very hard to disagree with the fact that there is probably little money to be made out of it.

How to make money out of Open Source

When we moved on from a purely Open Source jOOQ to a dual-licensed one, we were criticised a lot by people who realised that they might fall into the dual-licensing category who no longer gets to ride for free. This was of course a disappointing evolution for those people. We see it as one step forward for a product that doesn’t just want to implement l’art pour l’art. We believe that we’re adding value on a small scale to a select set of customers with real SQL problems, and we want to continue to do so. Thus, commercial interests are now the driving force behind our developments, and dual-licensing is the easiest way to achieve that on our own small scale.

Many of those who had criticised us claimed that we should create a support-based Open Source business model instead (like Pivotal!). In other words: Let “them” pay for support – whoever “they” are. But that is not a viable model in the long run.

We create fishing poles. We don’t want to compete with our customers, the fishermen.

In software, the vendor of some product shouldn’t commoditize the main driver for innovation: The product. They should sell the product and create an ecosystem and a market for consultants that will be much better at applying the product to some concrete customer’s business. It is a win-win-win situation for everyone:

  • Vendors get money from licenses
  • Consultants get money from their specialist knowledge
  • End-users get a better, cheaper solution with a lower cost of ownership

Although, the consultant is always the one whose work is commoditized in the long run as demand for the product increases, and more consultants pop up trying to make money from their consulting business.

Joel Spolsky has written an extremely interesting Strategy Letter on the idea of commoditizing a complementary product (support, in this case) to increase the demand for the primary product (license, in this case). In the case of a PaaS company like Pivotal, however, we can only guess that even the commoditization of a whole programming language and ecosystem is no longer sustainable enough to increase demand for their PaaS offerings.

If that is the truth, then other platforms like Spring are at the stake as well! If Groovy is not sustainable, why should Spring be?

Am I Groovy?

Suis-je Groovy? To get back to the original claim:

No, I’m not Groovy. Groovy and every other piece of Open Source software that does not in any direct way produce a commercial value for both the vendor and the consumer is doomed to fail in the long run. Open Source software has created a tremendous amount of value in our industry. Companies like ourselves wouldn’t be possible if we’d still pay millions for an operating system license. The question is not whether software is free as in beer or as in freedom. The question is whether anyone has any viable commercial interests in making a particular software element cheap or even free. If they don’t, well, the joke will be on you as the vendor might just stop doing it. Open Source or not.

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.

Free as in Beer has caused Heartbleed (and Much More)

heartbleedHeartbleed is a bit over one month old now. A bug significant enough to have its own Wikipedia page. Today, we’re going to look into how wrong we have been in assuming that Open Source software is more secure than commercial software, because of our thinking that source code is open and that many developers are looking into it.

Free as in Beer

One of the core principles of Open Source software is, well, that it is open and that this openness is free in one way or another. This allows us developers to browse source code of third-party software and libraries for various reasons:

  • To learn from it
  • To copy it (under the terms of the respective license)
  • To modify it (under the terms of the respective license)
  • To verify it

Proprietary software often does not have the above attributes in exchange for warranties. When you read through the millions of lines of unintelligible legal Microsoft text, for instance, you will see that Microsoft gives a couple of guarantees, also with respect to security and how security flaws are remedied.

The warranty that is legally shouted at you by OpenSSL is this one:

THIS SOFTWARE IS PROVIDED BY THE OpenSSL PROJECT “AS IS” AND ANY EXPRESSED OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE OpenSSL PROJECT OR ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

In fact, you don’t have any warranties. Specifically, there is no liability for direct or indirect loss of data, as has happened because of Heartbleed.

Obviuous, right? Because it’s free as in beer, any consequences resulting from the Heartbleed bug are entirely your own fault, if you’re using OpenSSL, or any other open source software that includes OpenSSL under similar terms.

Yes. You should have known that you were vulnerable, because you actually could verify it. Did you? Of course not. Did we? No way we’re delving through all that C code. Did our “suppliers”? We don’t even know. We’re using WinSCP extensively, and check this out, WinSCP was affected by Heartbleed! The developers over at WinSCP have been nice enough to fix this issue quickly and release a new version. They didn’t have to do this. You know what? Let’s hit that donate button, right now to thank them.

“They” should pay

OK, but again, wasn’t Heartbleed supposed to never even happen? Isn’t this Open Source? Doesn’t anyone (read: “they”. Because, I don’t have time) review such code, especially if it’s that widely used? Isn’t Open Source security much better than closed source security, which is essentially security through obscurity?

Eberhard Wolff, a well-known German freelance consultant and trainer recently replied this to me:

Yes, I’m sorry, Eberhard. But that’s just the case. Security is often neglected in many pieces of software, both commercial and open source. It’s not that the openness helps anyone discover things, security issues are very hard to discover per se. Also in commercial software. Remember GOTO fail? GOTO fail also affected SSL, but only in Apple software.

The issue lies elsewhere, though. Because Microsoft somehow manages to patch all security issues in virtually no time. They fix things so fast that users get frustrated about the sheer frequency of fixes ;-)

Cartoon by http://www.stickycomics.com/computer-update/
Cartoon by www.stickycomics.com

But Microsoft has a lot to lose. Pretty much 90% of desktop OS market share, that’s what they’ve got to lose. They’re paying a high amount of insurance money, invested in security teams that are penetration testing their own software to look for leaks. Yes. The vendor themselves are doing this. And yes, it costs money. And yes, you’ve already paid that when you bought Windows (or Office for that matter).

Money that OpenSSL never had. Read this frustrated section in the following public letter by Steve Marquess:

Thanks to that publicity there has been an outpouring of grassroots support from the OpenSSL user community, roughly two hundred donations this past week[3] along with many messages of support and encouragement[4]. Most were for $5 or $10 and, judging from the E-mail addresses and names, were from all around the world. I haven’t finished entering all of them to get an exact total, but all those donations together come to about US$9,000. Even if those donations continue to arrive at the same rate indefinitely (they won’t), and even though every penny of those funds goes directly to OpenSSL team members, it is nowhere near enough to properly sustain the manpower levels needed to support such a complex and critical software product. While OpenSSL does “belong to the people” it is neither realistic nor appropriate to expect that a few hundred, or even a few thousand, individuals provide all the financial support. The ones who should be contributing real resources are the commercial companies[5] and governments[6] who use OpenSSL extensively and take it for granted.

I can feel with Steve. US$9,000 to improve OpenSSL, a software that has added so much value to all of our servers and clients. That’s hardly enough for even 2-3 bug fixes, depending on whose salaries you’re paying.

But Steve tells off the “commercial companies” and “governments” to not have paid enough. But who are these “commercial companies”?

Meanwhile, at Data Geekery

We know similar stories, of course. When we have transitioned from completely Open Source to dual-licensed, we heard a lot of complaints by users that we have never heard of up to that moment. Users who have never donated or contributed code, bug reports, manual improvements or anything. This is OK. We were giving jOOQ away for free under the terms of the ASL 2.0 as part of a extended market analysis. We didn’t expect donations.

Of course, we have also disappointed one or two people who were hoping that jOOQ would remain “free as in freedom”, who have contributed, who have participated, and who now felt deceived. And we’re genuinely sorry about that. But participation doesn’t pay for our bills, money does. So we reached out for money (luckily, we always owned the code as we paid contributors of larger contributions, and had them all sign a CLA, so we could actually do this step, from a legal perspective).

But let’s again focus on the people looking for free beer. No contributions. No feedback. Free rides. And then, when asked for money, they’re pissed (even 8 months later!).

Fair enough. Our price has risen for that particular user. From free to something. They, too, have a right to be frustrated about this change, which they might not have expected. But they, too, have taken “free” for granted without proper reason. Without verifying.

“They”

We don’t believe that “THEY” should pay for our licenses. We don’t think that “THEY” should pay for enterprise support. There is no “THEY” in free software, there’s only all of us, because who decides which project is really important enough to deserve some funding from “THEM” and which one isn’t? All attempts of “fairly” distributing money will inevitably lead to corruption, misuse, abuse, and eventually, to a lack of innovation. We’ve known that from other industries.

So, let’s simply establish two facts:

  • Free software is lying around in the streets. It is publicly acclaimed to be AS IS software. If we’re using it, it is our own risk. And if it goes wrong, it is our own fault. No one else’s. Not the big companies’ (who are already investing tons of money in Open Source software), and not the governments’ (same thing there). Stop pretending that FOSS is in any way better or less of a legal risk than commercial software. That’s just not true.
  • In fact, there is no such thing as free software. “Free” is a price we’re paying as a down payment (or non-payment). The costs will or might arise later. If we’re lucky, the thing will remain “free”. But if we’re professionals, then we’ll insure ourselves against any risk arising from free “AS IS” software. This means that we’ll give back (= “pay”) in another way. Through donations, through bug fixes, through verification.

Further reading

Bruno Borges from Oracle has expressed his very interesting views and counter measures to the current state and meaning of Open Source software in this blog post.

jOOQ Newsletter: January 22, 2014

Subscribe to the newsletter here

Tweet of the Day

We are contributing this new section of the newsletter to our followers, users, and customers. Here are:

Jose M. Arranz who has had plans to build jOOQ, when he happily discovered that jOOQ already exists

https://twitter.com/jmarranz/status/417956223468982272

Majid Azimi who wishes for jOOQ to become the new de facto standard in all languages. (we wish for the same, shocker, I know)

https://twitter.com/majidazimi/status/420879296807186432

jOOQ 3.3 Preview

We’re closing in on releasing jOOQ 3.3 towards the beginning of February 2014, which is an exciting release for both existing and new jOOQ users. Apart from many defects fixed, there are now also

… and much more. jOOQ Open Source Edition users can download a preview from GitHub, commercial users can request a pre-built download directly from us.

The Data Geekery Business Case at RedHat’s opensource.com

At Data Geekery, we’re in close touch with various communities, among which those by Oracle or RedHat. RedHat has been selling Open Source software as a business model for a long time. In the enterprise, apart from the flagship RHEL, RedHat is also providing support for a variety of other stacks, such as the JBoss platform, or cloud computing solutions

We’re thrilled to present to you our feature article on RedHat’s opensource.com platform, where we have published an article on our own commercial Open Source business case:

http://opensource.com/business/14/1/how-to-transition-open-source-to-revenue

This is the first part of a series of blog posts. In the next part, we’re going to talk about the five lessons learned when making a business of Open Source, so stay tuned!

Community Work

In the last few weeks, there had been a couple of excellent blog posts by jOOQ community members, which we do not want to keep from you. In December, Gregor Riegler has written a witty rant about the Annotation Nightmare, which we’re increasingly suffering from in the Java ecosystem. Declarative programming at its best.

In January 2014, Petri Kainulainen has started writing a series of excellent blog posts and tutorials for new jOOQ users. The first two posts he has written can be seen here:

Petri is a very active blogger, whom we have been following for a while now. We’re eagerly looking forward to future posts about jOOQ from him.

There are more goodies. Johannes Bühler has contributed new functionality around the loader API and JSON, whereas Darren Shepherd who is a very active contributor to Apache CloudStack has been very active on the jOOQ User Group as well, discovering many issues. Thank you very much for all your help, guys!

Upcoming Events

In January, we have been visiting the JUG-HH in Hamburg for our talk about jOOQ. This was a very exciting and welcoming event with a heavily “JPA / JEE – biased” audience. Thrilling to see how jOOQ (and SQL!) finds high resonance in this kind of industry!

Here is an overview of our upcoming events. We’re very happy to talk at geecon this year!

Stay informed about 2014 events on www.jooq.org/news.

SQL Zone – DEFAULT values

We’re always surprised ourselves at the depth and breadth of the SQL language, and we love share our discoveries with you. Few people know that in SQL (in the standard and in many SQL dialects), you can use the DEFAULT keyword in INSERT and UPDATE statements. Read more about DEFAULT VALUES on our blog.

SQL Zone – JDBC Batch

In heavy-throughput environments, SQL users rely on vendor-specific tools, such as Oracle’s SQL*Loader. In slightly less performance-critical environments, JDBC batch operations are still good enough. But how good are they compared to standalone statements? The answer is: very good. But not in all databases / JDBC drivers. We have found a very interesting benchmark by James Sutherland, which we want to share with you.

The Open Source Bikeshed.

“Him” or “They”? English language aficionados haven’t yet decided what to do with a singular pronoun of unknown (or irrelevant) sex. On Stack Exchange’s English Language and Usage site you can find lots of questions like this one, explaining the context.

Let’s talk about code. When coding, we also write documentation. When writing documentation, we tend to use the English language. According to Wikipedia, roughly 5% of the world’s population speak English as their native language. For the rest of us, “Him” or “Them” in documentation is an even more remote grammar challenge than for native speakers. Some may argue that it might not be as critical as maybe fixing a bug in a core banking system that causes the bank to “lose” 1 million [your currency] per minute.

Don’t get me wrong. I don’t want to trivialise the historic context. But if you’re not really into that context, discussing over “Him” vs. “Them” is just as interesting as discussing over “ISO 8859-1” vs. “UTF-8”. There’s a clear tendency towards doing the “better thing” in the long run (i.e. “Them” and “UTF-8”), and it’s good that better things are being established. But most people acknowledge that fact and then get back at fixing that other critical bug. In other words, most people don’t want to discuss the bikeshed.

However, this is not what 80 people on this GitHub pull request think. They take the time to publicly discuss

  1. The correct use of “Him” or “They” or “She” or “Them” or “One”
  2. The implications of the maintainer closing the pull request as “too trivial”
  3. The implications of the implications of people reacting to the offence

Now, if you follow OSS related blogs, or twitter, you will find lots of people getting incredibly involved with this topic. Take Joyent – a sponsor for the project at hand. On their blog, they reacted to this incident:

But while Isaac is a Joyent employee [having accepted the grammar-fixing pull request], Ben [rejecting the pull request] is not—and if he had been, he wouldn’t be as of this morning: to reject a pull request that eliminates a gendered pronoun on the principle that pronouns should in fact be gendered would constitute a fireable offense for me and for Joyent.

Joyent then continues by stating things like:

(Especially when that poor behavior transcended into the gobsmackingly inappropriate as Ben tried to revert Isaac’s commit.)

And then

Indeed, one of the challenges of an open source project that depends on volunteer effort is dealing with assholes

Source: http://www.joyent.com/blog/the-power-of-a-pronoun.

A reaction to the above made it on Hacker News, leading to another heated debate about the fundamentals of society, reproaches from all sides.

The Bikeshed in Open Source Software

We’re doing Open Source ourselves. We try to do it professionally, as we’re trying to make Open Source our business model. As with any business, it is not always easy to remain professional. People have weaknesses. People have convictions, visions and a cultural background. But there is one thing that Open Source has, unlike closed source businesses. It is immensely open and public. This means that a rather trivial situation about a very local problem that would otherwise be settled among 3-4 involved employees suddenly escalates, turns public and leads to tremendous ranting, shouting, insulting on social media, such as:

  • Blogs
  • Twitter
  • GitHub
  • Hackernews

People have invested a lot of energy into this particular Open Source bikeshed, going as far as publicly pilloring one of the people involved over their use of pronouns in the English language. As it seems ever so often, Open Source is not about software. It is about people, in all of their good and bad ways.

Oracle GlassFish, or Why You Should Think About Open Source Again

Oracle’s recent announcement about the discontinuation of commercial services for JEE’s reference implementation GlassFish has caused many reactions in the community involved with JEE. The reactions reach from:

This event seems to have a big impact on the whole Java ecosystem as many of the above people are key players and influencers in our community, and they neither agree nor know what this step by Oracle means for the future of JEE.

The most interesting point of view among all of the above, in my opinion, is tomitribe’s, looking at things from a mere business point of view with respect to Open Source. They’re saying:

Open Source Isn’t Free

Or in other words, “There ain’t no such thing as a free lunch”. And to quote tomitribe even more, a very interesting thought they’re setting out is this:

What this says to me is that we as an industry still do not fully understand Open Source.

We most certainly do not understand Open Source. I’m an Open Source software vendor myself. I believe that Open Source is:

An excellent marketing tool

People look at Open Source as something “generally good”. When I talked about jOOQ at conferences and when it was an all-Open-Source piece of software (not yet dual-licensed), I got lots of opportunity to do free advertising. This has rapidly changed, now that I am offering an alternative commercial license.

A good tool enabler

I get free access to

The same here. As I’m now a “commercial” software vendor, some tools are no longer accessible to me.

The truth is: Open Source is a business strategy

It really is. And it seemed to have worked well for RedHat or Pivotal in the past. Has it worked for anyone else? We don’t know yet, as most other larger companies have such huge amounts of revenue in “classic” fields that they can simply “afford” Open Source. In fact, they’re so good at investing manpower and innovation into Open Source, it keeps the commercial competition in check, as it is hard to write a better and more complete JEE implementation than Weblogic or Websphere.

Apparently, even Larry Ellison is said to agree that the future of data centers lies within using commodity machines. At the same time, RedHat suggests “trying free” to Oracle.

No matter what the impact of the commercial unsupport of GlassFish on JEE will be, we’re only at the beginning of fully understanding what kind of impact this large scale “freemium” model will have on our world. This isn’t just about the software industry. The whole Internet has brought us “free” stuff. We get:

  • “Free” standards (compare W3C, IETF standards to ISO standards!)
  • “Free” Facebook and Twitter and GMail accounts
  • “Free” newspapers
  • “Free” music and films
  • “Free” commodity services for all sorts of work
  • “Free” work force as we can offshore anything to low-wage countries

This has been picked up recently by Tim Kreider, the author of “We Learn Nothing”, where he depicts how writing “free stuff” for the New York Times helps building “exposure”, and how that’s just nonsense as all this hard journalist work doesn’t pay anymore.

Does building “exposure” ring a bell?

Yes, I can build “exposure” by writing free Open Source on GitHub, and by answering complex questions for free on Stack Overflow. I personally use both tools to advertise jOOQ, no doubt. So I get a service (advertising) for a service (content). My deal appears fair to me. But loads of GitHub and Stack Overflow users contribute … just for the sake of contributing. To whom? To GitHub and Stack Overflow. And why? I don’t know.

So, should you contribute to GlassFish, if Oracle starts decreasing support and loosening interest as they have before with MySQL, Hudson, and other products inherited from Sun?

Let’s remember that Karl Marx has already taught us that our idea of capitalism will inevitably lead us to (citing from Wikipedia):

  • technological progress
  • increased productivity
  • growth
  • rationality
  • scientific revolution

Absolutely! There’s no way that productivity can get any better than by having loads of software developers world wide produce better and better tools (growth, progress) for nothing more than … for free!

So, don’t be a pawn of others’ Open Source strategies

So, instead of contemplating what Oracle’s move away from supporting the Open Source reference implementation of JEE means, become active yourself! Don’t just blindly consume Open Source, make it an option like any other option by consciously deciding in favour of Open Source or commercial software, depending on your specific needs.

Stop advertising their cool products for free at conferences, unless you pull out your own advantage from such an advertisement. Open Source is just yet another business model.

A Significant Difference Between Open Source and Commercial Software

A recent event has triggered a lot of interest in the debate about the good and the bad parts of Open Source. Oracle’s attack on Open Source. For large corporations who aren’t Red Hat, taking a stand on the topic is far from easy. Oracle used to sell only commercial software, but has since acquired a lot of open-sourcey companies, such as Sleepycat Software (BerkeleyDB) or Sun Microsystems (Java, MySQL). Phrasing a long-term strategy upon this legacy isn’t easy.

At the same time, Oracle is extremely successful, having surpassed IBM’s revenue, making Oracle the second largest software company in the world. The continuing popularity of its flagships Java and the Oracle database is promising, also for middleware vendors providing products such as jOOQ, for their flagships.

At Data Geekery, Open Source is also very important, just as commercial licensing has become, since recently. The change towards dual-licensing has been received rather positively on the jOOQ user group, even if it led to open questions about the continued Open Source strategy. But what’s the real difference between Open Source and commercial software? At Adobe, Dr. Roy Fielding is often cited saying that there is essentially no difference between Open Source and commercial software, and he’s quite an authority for both worlds. Both are absolutely viable business models with their pros and cons respectively (unfortunately, I cannot back this up with an actual citation).

One significant difference, however, is that low-quality open source software can heavily outlive low-quality commercial software, as it just never really dies, as no one is “losing money” on low OSS “sales”. I’ve recently blogged about how to recognise such low-quality Open Source software.

Open Source is foremost a business and marketing strategy, just as much as it is a mission. This business strategy can be a good or a bad choice for any software vendor.

jOOQ™ 3.2 Offering Commercial Licensing and Support

Four years ago, the Java database middleware market was dominated by a variety of ORMs implementing JPA. This paradigm was hardly challenged by alternatives. There was a gap for an API making SQL a first-class citizen in the Java language ecosystem and jOOQ had come to fill this gap. With jOOQ, developers who engage heavily in writing SQL finally had a tool that helped them express SQL almost natively in the Java language, leveraging the Java 6+ compiler’s features to validate their SQL statement’s syntax and type correctness. In the last four years, jOOQ had become increasingly popular and mature. jOOQ is used by many demanding customers operating on large and complex databases. The feedback that we have had from those customers was unanimously positive, although there was one thing missing. That one missing thing was professional support, warranties, and thus commercial licensing. With the new jOOQ 3.2, apart from introducing great new features, we are changing quite a few things on how we operate.

jOOQ is now jOOQ™
After jOOQ 3.1, we have now published jOOQ™ 3.2

At Data Geekery GmbH, we believe in Open Source. But we also believe in the creative power enabled by commercial software. This is why we have chosen to implement the following dual-licensing strategy:

  • Users using jOOQ with popular Open Source databases will continue to be able to get our high-quality, integration-tested Apache Software License 2.0 licensed free Open Source distribution from Maven Central, from GitHub, or from the jOOQ website. At the same time, they will continue to profit from our free community support in English on the jOOQ User Group.
  • Users using jOOQ with commercial databases will be able to profit from our competitive commercial jOOQ subscription licenses, which include support for commercial databases, as well as professional support in English, German, and French, early access to releases and bugfixes, warranties, custom engineering and much more.
license-models
Our license models

Of course, customers using jOOQ with an Open Source database can also purchase a commercial license subscription, if they wish to profit from our professional support and services. In the following FAQ, we’ll answer to some questions you may have:

Why offering a workstation license?

We believe that the main added value of jOOQ is added to our customer’s development lifecycles. jOOQ helps developers write SQL code in 10% of the time they needed if they had used JDBC or other String-based approaches directly. At the same time, jOOQ and its powerful source code generator help prevent coding mistakes early in the development lifecycle, preventing 90% of the usual SQL mistakes. jOOQ is thus a development tool, as opposed to a database, which is a storage tool adding most value at runtime. This is why jOOQ offers a workstation license, as opposed to most databases offering server licenses.

Why not just offering support for an all-Open-Source library?

We’re aware of vendors that sell all-Open-Source software, making money only with expensive support subscriptions. This is a viable model for vendors offering server software, such as databases, where 24/7 support is very crucial. It is also a viable model for vendors offering very complex software, which needs a lot of additional, costly consulting efforts. jOOQ is none of the aforementioned. It is middleware, which is very easy to use and will not generate any consulting business as it adds almost no complexity on top of SQL itself. We have challenged our decision with a variety of existing users and customers, and we firmly believe that we can add most value with a dual-licensing model that builds upon dependent database licensing models. After all, spending a bit of money on a jOOQ license will save our customers an incredible amount of money on their development lifecycle with powerful databases like DB2, Oracle, SQL Server, or Sybase.

Why stick with the Apache License?

The Apache License has served us well in the past four years. It is very liberal while at the same time, protecting our trademarks. It is a license that has enabled us to grow and get lots of high quality community feedback and contributions. We do not want to follow suit with other dual-licensing companies who go down the *GPL path, as we believe that dual-licensing *GPL software is not true to the spirit of Open Source Software in the long run. By staying with the Apache License, we want to express our deep commitment to Open Source.

What about contributor copyrights?

We take copyrights seriously. This is why we had our major contributors sign an agreement to transfer all copyrights to us. While we need to settle copyrights, we still want to publicly attribute authorship to those contributors who have shared code or documentation with us. Of course, we also welcome all future contributions by our community! Should you as a contributor feel that your copyrights are challenged or infringed by our dual-licensing, please do contact us directly.

What happened to the jOOQ Console?

While the jOOQ Console 3.1 will continue to be available to jOOQ 3.2 users from Maven Central, the jOOQ Console development has been stopped in its current form. It will make room for a new, commercial profiler software that Data Geekery will develop in the near future, stay tuned.

Why do this at all?

Because we want to show our commitment to jOOQ, which is much more than a library. It is a vision of a better Java and SQL integration. It is innovation in various fields of the Java ecosystem. We want to:

  • Support those who love both Java and SQL and who were denied appropriate tooling, in the past.
  • Further develop the integration of internal domain-specific languages in Java, by formalising language aspects of software like jOOQ. Not just for jOOQ.
  • Expand our high-quality SQL integration into the Scala ecosystem by offering a native Scala API – and possibly core.
  • Further improve the jOOQ Console to provide more high-quality development tooling.
  • Make our SQL knowledge available to our customers through our blog and source code.

In order to implement the above plans, we need to create a business from jOOQ. And we believe that this business will be extremely interesting both to us and to our customers. Together, as the jOOQ ecosystem, we’ll create a better Java/SQL world! Let us start with jOOQ 3.2!

10 Reasons not to Choose a Particular Open Source software

We’re all Software Engineers of one type or another. Most of us have one thing in common, though: We’re lazy. And we know that someone else was less lazy and has already solved that tedious problem that we’re on. And because we’re not only lazy but also stingy, we search for Free Open Source software.

But the problem with Open Source software is: There are millions of options for about every problem domain. Just look at web development with “modern” JavaScript. Which tool to choose? Which one will still be there tomorrow? Will it work? Will I get maintenance? New features? Plugins from the community?

While it is not so easy to find the right tool among the good ones (commons or guava? mockito or jmock? Hibernate or jOOQ or MyBatis?), it is certainly easier to rule out the bad ones.

Here are some things to look out for, when evaluating an Open Source software (in no particular order)

1. NullPointerExceptions, ClassCastExceptions

This is one of my favourites. It is very easy to google. No one is completely safe from these annoyances. But when you find stack traces, bug reports, investigate them closely.

  • Do they appear often?
  • Do they appear in similar contexts?
  • Do they appear in places where they could’ve been omitted?

It’s a matter of good design to be able to avoid NullPointerExceptions and ClassCastExceptions. It happens to everyone. But no NullPointerException should be thrown from a place that can be statically discovered by the Java compiler or with FindBugs.

Needless to say that the list of no-go exceptions thrown from a database library, for instance, can be extended with SQLExceptions due to syntax errors produced by that library.

2. Community Discussing Bugs instead of Features, Strategies, Visions

Every Open Source software has users and with Google Groups and GitHub, it has become fairly easy to interact with an OSS community.

For larger projects, the community also extends to Stack Overflow, Reddit, Twitter, etc. These next steps are a sign of popularity of an Open Source software, but not necessarily a sign that you should use them. Also, don’t be blinded by users saying “hey this is so cool”, “it just made my day”, “best software ever”. They say that to everyone who’s supporting them out of their misery (or laziness, see the intro of this post).

What you should be looking out for is whether the community is discussing visions, strategies, features, truly awesome ideas that can be implemented next year, in the next major release. It’s a true sign that not only the software will probably stick around, it will also become much better.

The converse to this is a community that mainly discusses bugs (see NullPointerException, ClassCastException). Unlike a “visionary” community, a “buggy” community will just create work, not inspiration to the vendor. But which one’s the chicken, which one’s the egg?

Another converse to this is a community that is disappointed by the false promises given by the visions of the vendor. I often have a feeling that Scala’s SLICK might qualify for that as it introduces an insurmountable language-mapping impedance mismatch between its own, LINQ-inspired querying DSL and SQL.

3. Poor Manual, Poor Javadoc

That’s easy to discover. Do you really want that? The best and most authoritative information should come from the software vendor, not some weirdo forum on the web that you’ve googled.

A good example are PostgreSQL’s Manuals.

A rant about bad examples can be seen here:
http://www.cforcoding.com/2009/08/its-time-we-stopped-rewarding-projects.html

Don’t be deceived by the idea that it might get better eventually. Poorly documented software will be poor in many other aspects.  And it’s such an easy thing to discover!

Of course, the “right” amount of documentation is an entirely other story…

4. No Semantic Versioning

Search for release notes and see if you’ll find something that roughly corresponds to semver.org. You will want patch releases when your Open Source software that you’re using in mission-critical software fails. When you get a patch release, you don’t want 50 new features (with new NullPointerExceptions, ClassCastExceptions).

5. Unorganised Appearance

Again, we’re in times of GitHub. The good old CVS times are over, where HTML was still used to share cooking recipes. Check if your Open Source software uses those tools. If they show that they’re using them. It will help you ascertain that the software will still be good in a couple of years if the vendor isn’t crushed by the mess they’ve gotten themselves in.

6. Vendor Side-Project evolving into an Offspring Product

Now that is a sign not everyone may agree upon, I guess. But after the experience I’ve made in previous jobs, I strongly believe that software that has evolved out of necessity before making it a product really suffers from its legacy. It wasn’t a product from the beginning and it has strong ties to the vendor’s original requirements, which doesn’t bother the vendor, but it will bother you. And because the vendor still has very strong ties to their offspring, they won’t be ready to make fundamental changes in both code and vision!

Specifically, in the database field, there are a couple of these software, e.g.

Note, I don’t know any of the above tools, so they may as well be awesome. But be warned. They weren’t designed as products. They were designed for a very narrow purpose originating from a pre-Apache context.

7. Generics are Poorly (or Overly) Adopted

Generics were introduced in 2004 with Java 5. Now that the heated debates about generic type erasure are over, generics are well adopted. Or aren’t they? The latest stable release 3.2.1 of Apache Commons Collections is still not generified! That must’ve been the number 1 reason why people had started shifting to Google Guava (or its predecessors) instead. There’s not much making for a lousier day than having raw types (or eels) slapped around your face.

The other thing that you should look out for, though, is over-generification. Generics can become really hard, even for top-shot Java architects. A common blunder is to strongly correlate subtype polymorphism with generic polymorphism without being aware of the effects. Having too many generics in an API is a good sign for an architecture astronaut. (or a design astronaut in this case). We’ll see further down how that may correlate with the person behind the design decisions.

8. Vendor Cannot Handle Objective Criticism or Competition

Here’s how to find out, who’s behind the Open Source software. While this isn’t important for a small, geeky tool, you should be very interested in the vendor as a person when looking for a strategic OSS addition, especially if you’re dealing with a benevolent dictator. The vendor should be:

  • Aware of competition, i.e. they’re doing marketing, learning from them. Improving to compete. This means that they are interested in being truly better, not just “convinced that they’re better”.
  • Open minded with their competition, with you as a customer, and ready to discuss various points of view.
  • Interested in new ideas, possibly putting them on a roadmap right away (but without losing focus for his main strategic roadmap).

Even if this is Open Source, there’s no point in being arrogant or conceited. The vendor should treat you like a customer (as long as you’re not trolling). Open-mindedness will eventually lead to the better product in the long run.

9. Vendor has no Commercial or Marketing Interests at All

Now, (Free) Open Source is nice for many reasons. As a vendor, you get:

  • Feedback more quickly
  • Feedback more often
  • Community (with pull requests, feature additions, etc.)
  • The feeling that you’re doing something good

True? Yes. But that’s true for commercial software as well. So what’s the real reason for doing Open Source? It depends. Adobe for instance has started opening up a lot, recently, since their acquisition of Day Software. All of JCR, JackRabbit, the upcoming JackRabbit Oak, Sling and Felix are still at Apache with the original committers still on board. But one can certainly not say that Adobe has no commercial interests.

OSS vendors should think economically and build products. Eventually, they may start selling stuff around their core products, or separate community and commercial licenses. And unlike they get too greedy (see Oracle and MySQL, vs RedHat and MariaDB), that can make commercial Open Source a very interesting business, also for the customer who will then get the good parts of Open Source (partially free, open, with a vibrant community) along with the good parts of commercial software (premium support, warranties, etc.)

In other words, don’t choose overly geeky stuff. But you might have recognised those tools before (poor documentation, no semantic versioning, poor tooling).

10. No Traction Anymore

To wrap this up, here’s an obvious last one. Many Open Source products don’t show any traction by the vendor. That goes along well with the previous point, where the vendor has no commercial interest. Without commercial long-term interest, they’ll also lose all other interest. And you’re stuck with maintaining a pile of third-party code yourself (fixing its many many ClassCastExceptions, NullPointerExceptions).

TL;DR : Conclusion

You should chose Open Source just like commercial software. Economically.

  • Open Source is not an excuse for bad quality.
  • Open Source is not an excuse for lack of support.
  • Open Source is not an excuse for non-professionalism.

If Open Source fails you on any of the above, the joke will be on you, the customer. You’ll get a bad product, and you’ll pay the price with exaggerated maintenance on your side, which you thought you’d avoid by chosing something free. Nothing is free. Not even Free Open Source. Ask the Grumpy Nerd