Reality of Open Source Users in Mobile and Cloud Era

- "I built my Android app entirely with Open Source products, both in the app, and in the backend server running on Amazon. I'm charging US$ 1,99 for it in the Google Play Store" 

- "That's wonderful! Where is the source code of your app? Have you contributed back to these Open Source products? Will you release your product as Open Source?"

In this new era of Cloud Computing and Mobile apps, there's an increasing number of for-profit products that takes advantage of Open Source products, but barely contribute anything back to them, either by buying support, or non-expensive things such as reporting bugs, fixes, or helping documentation. Developers are building SaaS applications for Salesforce.com, or Mobile apps for Android and iOS devices, and usually charge for these. Of course, they want to make money as anyone else.

Whenever I ask someone that makes money with _their_ software built on top of Open Source, if they will ever release the source code, they usually answer: "my case is different". Well, why is your case different? Why can't I buy your app from Google Play Store, and still access the code on GitHub? Or build it on my own, customize it, etc? That's the point of Open Source, right? Wrong, in their minds.

Majority of software developers actually tend to think that Open Source is free as in free beer. And that's it. No matter how hard you try to explain otherwise, the industry will almost always see Open Source software as free software. And due to the new way to sell software, I really think that Mobile apps and Cloud SaaS/PaaS offers will, sooner or later, kill good Open Source softwares, and leave this space only for conceptual and initial implementations for Open Standards and APIs, or for general use and development platforms and languages such as Java, Ruby, etc.

Perhaps you want to read Will Cloud kill Open Source? Is the Future Open Standards? Your thoughts are welcome :-)

6 Facts About GlassFish Announcement

Since Oracle announced the end of commercial support for future Oracle GlassFish Server versions, the Java EE world has started wondering what will happen to GlassFish Server Open Source Edition. Unfortunately, there's a lot of misleading information going around. So let me clarify some things with facts, not FUD.

Fact #1 - GlassFish Open Source Edition is not dead

GlassFish Server Open Source Edition will remain the reference implementation of Java EE. The current trunk is where an implementation for Java EE 8 will flourish, and this will become the future GlassFish 5.0. Calling "GlassFish is dead" does no good to the Java EE ecosystem. The GlassFish Community will remain strong towards the future of Java EE. Without revenue-focused mind, this might actually help the GlassFish community to shape the next version, and set free from any ties with commercial decisions.

Fact #2 - OGS support is not over

As I said before, GlassFish Server Open Source Edition will continue. Main change is that there will be no more future commercial releases of Oracle GlassFish Server. New and existing OGS 2.1.x and 3.1.x commercial customers will continue to be supported according to the Oracle Lifetime Support Policy. In parallel, I believe there's no other company in the Java EE business that offers commercial support to more than one build of a Java EE application server. This new direction can actually help customers and partners, simplifying decision through commercial negotiations.

Fact #3 - WebLogic is not always more expensive than OGS

Oracle GlassFish Server ("OGS") is a build of GlassFish Server Open Source Edition bundled with a set of commercial features called GlassFish Server Control and license bundles such as Java SE Support. OGS has at the moment of this writing the pricelist of U$ 5,000 / processor. One information that some bloggers are mentioning is that WebLogic is more expensive than this. Fact 3.1: it is not necessarily the case. The initial edition of WebLogic is called "Standard Edition" and falls into a policy where some “Standard Edition” products are licensed on a per socket basis. As of current pricelist, US$ 10,000 / socket. If you do the math, you will realize that WebLogic SE can actually be significantly more cost effective than OGS, and a customer can save money if running on a CPU with 4 cores or more for example. Quote from the price list:

“When licensing Oracle programs with Standard Edition One or Standard Edition in the product name (with the exception of Java SE Support, Java SE Advanced, and Java SE Suite), a processor is counted equivalent to an occupied socket; however, in the case of multi-chip modules, each chip in the multi-chip module is counted as one occupied socket.”

For more details speak to your Oracle sales representative - this is clearly at list price and every customer typically has a relationship with Oracle (like they do with other vendors) and different contractual details may apply.

And although OGS has always been production-ready for Java EE applications, it is no secret that WebLogic has always been more enterprise, mission critical application server than OGS since BEA. Different editions of WLS provide features and upgrade irons like the WebLogic Diagnostic Framework, Work Managers, Side by Side Deployment, ADF and TopLink bundled license, Web Tier (Oracle HTTP Server) bundled licensed, Fusion Middleware stack support, Oracle DB integration features, Oracle RAC features (such as GridLink), Coherence Management capabilities, Advanced HA (Whole Service Migration and Server Migration), Java Mission Control, Flight Recorder, Oracle JDK support, etc.

Fact #4 - There’s no major vendor supporting community builds of Java EE app servers

There are no major vendors providing support for community builds of any Open Source application server. For example, IBM used to provide community support for builds of Apache Geronimo, not anymore. Red Hat does not commercially support builds of WildFly and if I remember correctly, never supported community builds of former JBoss AS. Oracle has never commercially supported GlassFish Server Open Source Edition builds. Tomitribe appears to be the exception to the rule, offering commercial support for Apache TomEE.

Fact #5 - WebLogic and GlassFish share several Java EE implementations

It has been no secret that although GlassFish and WebLogic share some JSR implementations (as stated in the The Aquarium announcement: JPA, JSF, WebSockets, CDI, Bean Validation, JAX-WS, JAXB, and WS-AT) and WebLogic understands GlassFish deployment descriptors, they are not from the same codebase.

Fact #6 - WebLogic is not for GlassFish what JBoss EAP is for WildFly

WebLogic is closed-source offering. It is commercialized through a license-based plus support fee model. OGS although from an Open Source code, has had the same commercial model as WebLogic. Still, one cannot compare GlassFish/WebLogic to WildFly/JBoss EAP. It is simply not the same case, since Oracle has had two different products from different codebases. The comparison should be limited to GlassFish Open Source / Oracle GlassFish Server versus WildFly / JBoss EAP.

But the message now is much clear: Oracle will commercially support only the proprietary product WebLogic, and invest on GlassFish Server Open Source Edition as the reference implementation for the Java EE platform and future Java EE 8, as a developer-friendly community distribution, and encourages community participation through Adopt a JSR and contributions to GlassFish.

In comparison

Oracle's decision has pretty much the same goal as to when IBM killed support for Websphere Community Edition; and to when Red Hat decided to change the name of JBoss Community Edition to WildFly, simplifying and clarifying marketing message and leaving the commercial field wide open to JBoss EAP only. Oracle can now, as any other vendor has already been doing, focus on only one commercial offer.

Some users are saying they will now move to WildFly, but it is important to note that Red Hat does not offer commercial support for WildFly builds. Although the future JBoss EAP versions will come from the same codebase as WildFly, the builds will definitely not be the same, nor sharing 100% of their functionalities and bug fixes. This means there will be no company running a WildFly build in production with support from Red Hat.

This discussion has also raised an important and interesting information: Oracle offers a free for developers OTN License for WebLogic. For other environments this is different, but please note this is the same policy Red Hat applies to JBoss EAP, as stated in their download page and terms. Oracle had the same policy for OGS.

TL;DR;

GlassFish Server Open Source Edition isn’t dead. Current and new OGS 2.x/3.x customers will continue to have support (respecting LSP). WebLogic is not necessarily more expensive than OGS. Oracle will focus on one commercially supported Java EE application server, like other vendors also limit themselves to support one build/product only. Community builds are hardly supported. Commercially supported builds of Open Source products are not exactly from the same codebase as community builds.

What's next for GlassFish and the Java EE community?

There are conversations in place to tackle some of the community desires, most of them stated by Markus Eisele in his blog post. We will keep you posted.

Will Cloud kill Open Source? Is the Future Open Standards?

Before you think I'm FUD'ing here, please note that there are already plenty of articles discussing this. Do a search for Open Source vs Open Standards on Google. You might be surprised. The oldest article I found in the first result page is one by Jonathan Schwartz from 2003, titled Open source versus open standards. Then there's another one called ZDNet: Open source vs open standards from 2004. Then there's another interesting one called Open Source vs. Open Standards, by Bob Sutor, from 2006-2009. There's another more recent one from this year, titled Open Standards And Open Source.

But if you payed attention, you might have noticed that none of these articles have the word CLOUD in it. And that's what differs from this blog post you are about to read.

Here is an interesting trend from Google to start this discussion.

Clearly, the interest in Cloud is going up, where interest of Open Source is going down in an almost equivalent proportion. Is the Cloud Computing era going to kill Open Source? I dunno. But this should warn us of one thing: that the Cloud era is not about Open Source. It is about Open Standards (and APIs).

As we all know, APIs expose functionality, not implementation, where the beauty of Open Source is that we all can look at the source code and be sure of how the implementation works, how the pieces are put together to make our application run. If you are a truly defender of Open Source, you are probably thinking right now that there is a company that offers a Cloud platform based on an Open Source software. But do you have access to the runtime? Can you be sure that they are running the exact same code as they tell you? Will they give you access to the server to check if the MD5 is the same? Even the Linux they say they are using might be different. You just cannot be sure. You don't own the infrastructure.

If we take the main 3 types of Cloud offers: SaaS, PaaS, and IaaS, only the latter we can be *more* sure, but still not 100% sure that our applications are running on top of Open Source software. Do you have access to the provisioning code that Amazon AWS uses to create your Linux instance? Do you have access to the source code of the network configuration utility? No. You say your project runs on top of 100% Open Source software. Then you tell me you are running your application at Amazon, or Azure, Oracle, Jelastic, CloudBees, CloudFoundry, etc? You are not running over only Open Source code. You are not. Your application relies on closed-source code to run on that Cloud. There will always be at least one component of that cloud that is not open sourced. And if the cloud provider tells you it is, "and here's the source code", you can't simply believe because you can't make sure of it, you can't see it in the runtime machine. You don't own that.

Now everyone is talking about moving to the Cloud. What will happen if everyone moves their application to some kind of Cloud? In a very extremist view, there would be no more software for on premise deployments, including Open Source. Or at least these would reduce drastically. There would be only... Open Standards.

Which in fact is what developers need these days for Cloud Computing: Open Standards. We all want to be able to move applications from a vendor to another, all it takes is to the other vendor support the same APIs that I require. Are Open Standards the future for Cloud Computing? APIs for SaaS (REST APIs), platforms for PaaS (Java EE), and standards for IaaS (OpenStack)?

Here's another interesting article that also talks about this: Open Standards are the key to True Cloud. Not Open Source Stacks.

I agree with Bruno Souza, where we quickly discussed the ideas I shared here. Open Source will live forever, and it will be the place where Open Standards will probably come up from. It is a de facto. This is how the JCP already works for example.

Which brings us to another question: will Cloud drive the openness characteristic of Open Source less open, and focus more on ideas for Open Standards? Will the Cloud business suggest Open Source as initial implementations for those ideas? What do you think?

Java SE 7 update 40 e o Mission Control 5.2

Chegou uma nova atualização do Java SE 7: update 40. Esta versão inclui várias novas funcionalidades como o Java Mission Control, Deployment Rule Set, suporta para o Retina display no Mac, e suporte a Hard Float ABI no Linux ARM v7. Também inclui diversas correções de bugs. Para quem desenvolve Applets e aplicações Java Web Start, este release, fica a atenção para conhecer e enteder as mudanças.

Deployment Rule Sets

Esta funcionalidade permite um administrador de desktops a controlar o nivel de compatibilidade para clientes Java assim como níveis de segurança para a empresa. Para maiores detalhes, veja a documentação do Deployment Rule Set.

Java Mission Control

O Mission Control era até então uma ferramenta disponível para clientes Oracle, e que foi lançada há muito tempo atrás junto com o JRockit (JRMC). Mas a Oracle agora disponibilizou a ferramenta junto com a JRE HotSpot 7u40. 

Esta ferramenta permite monitorar, gerenciar, introspectar, e detectar memory leaks nas suas aplicações Java, sem ter que introduzir códigos para isso, que normalmente degradam a performance da aplicação. Hoje esta ferramenta está agora disponível no download do Oracle HotSpot JDK 7u40!

Flight Recorder

Mas a principal e mais importante característica é o Flight Recorder. Este recurso funciona através da leitura de eventos produzidos pela JVM. Mesmo ativando a geração destes eventos, a sobrecarga total  para as suas aplicações ainda fica abaixo de 2%, que considerando o tipo e o valor de informação que você recebe, é quase nada. Um exemplo de evento é a chamada de um método de uma classe Java.

Com o profile de chamadas de métodos você pode descobrir onde o aplicativo está gastando a maior parte do tempo executando seu código Java. Este é, por exemplo, útil para otimizar a aplicação onde as otimizações realmente terão impacto. Isto sem precisar introspectar seu código manualmente!

Alem disso, você tem também uma visão de otimização para alocação de objetos. Você pode ver por exemplo, a alocação em tempo real de objetos na Old Gen da memória heap. diretamente no espaço de idade, além de outras abas que oferecem diversas informações importantes sobre o processamento de informações na sua aplicação Java. Leituras de arquivos I/O, Socket I/O e muito mais.

Se você precisa de mais informações sobre o Mission Control, entre na página da ferramenta em www.oracle.com/missioncontrol.

E obrigado ao Markus Eisele por ter cedido parte deste post! :-)

Install Fusion Middleware Infrastructure on Oracle DB 12c

This week I had the opportunity to play a little with the new and recently released Oracle DB 12c. This version brings a new approach for databases, calledPluggable Databases. There are plenty of articles and YouTube videos already explaining this and I will not focus this article on it. Instead, I want to help you on How to Install Oracle Fusion Middleware Infrastructure on Oracle DB 12c.
There are a couple of steps and commands to be followed, and some very important observations. Starting with a simple one:

Do NOT execute the RCU installer on top of a CDB.
One more time: do NOT execute RCU on top of a CDB. 

If you do point the RCU tool to install over a CDB, you might get this message:

ORA-65096: invalid common user or role name

Now with this in mind, I believe you have understood that the first step is, obviously, to create a PDB. There are some options, but I will use pure SQL commands.

Step 0 - Use the correct encoding for your Database install

Make sure you have installed your DB with the AL32UTF8 encoding. 

This is recommended, but it might work in case you are using something else.

Step 1 - Create a PDB to hold the FMW Infrastructure Data

The following command will create a PDB called PDBFMW with a user "fmw" and password "welcome1".

SQL> CREATE PLUGGABLE DATABASE PDBFMW ADMIN USER fmw IDENTIFIED BY welcome1
 FILE_NAME_CONVERT=(
  '/u01/app/oracle/oradata/orcl/pdbseed/system01.dbf', 
  '/u01/app/oracle/oradata/orcl/pdbfmw/system01.dbf',
  '/u01/app/oracle/oradata/orcl/pdbseed/sysaux01.dbf', 
  '/u01/app/oracle/oradata/orcl/pdbfmw/sysaux01.dbf',
  '/u01/app/oracle/oradata/orcl/pdbseed/pdbseed_temp01.dbf', 
  '/u01/app/oracle/oradata/orcl/pdbfmw/pdbfmw_temp01.dbf'
  )
 STORAGE UNLIMITED

Please make sure to adjust the values to your installation. 

Step 2 - Open the PDB for changes

After you have the PDB created, make sure you change its state to READ_WRITE

SQL> ALTER PLUGGABLE DATABASE PDBFMW OPEN READ WRITE

Step 3 - Fix user privileges

Now you must make sure the user "fmw" has all required privileges. As this is for Development, I will just give everything.

SQL> GRANT ALL PRIVILEGES TO fmw WITH ADMIN OPTION
SQL> GRANT SYS TO fmw

* Important note: I'm not a DBA expert and these might not be the correct privileges for production environment. So please make sure to give only the necessary privileges following the documentation.

Step 4 - Run the RCU tool

This step considers that you have correctly installed Fusion Middleware Infrastructure into your Middleware Home / WebLogic installation folder. In my case, I'm using the full WebLogic + JDeveloper installation package, which brings the FMW Infra bundled. Now go to your $MW_HOME folder and run the RCU tool:

$ cd $MW_HOME

$ cd oracle_common/bin
$ ./rcu

Make sure to use the correct properties to connect to your recently created Pluggable Database:

Database Type: Oracle Database
Host Name: db12c (change to your DB IP address)
Port: 1521
Service Name: pdbfmw (here you use the PDB name)
Username: fmw
Password: welcome1 (or whatever you defined)
Role: SYSDBA

Click "Next" and see if it worked. If you are not using AL32UTF8, it will ask you to Ignore. Just do it, but remember: it might not work properly.

Step 5 - Select components and create new prefix

I like to select everything, and use the "FMW" prefix. Click "Next", "Next", "Next", etc, etc, etc... Until it finishes.

FINISHED!

You have successfuly created the right database structure for your Fusion Middleware Infrastructure, and now you can create a WebLogic domain with ADF and everything else, pointing to this PDB.

If you have any question, post a comment!