Ulterior Motives and Forces Surrounding Software Technology Standards
Ulterior Motives and Forces Surrounding Software Technology Standards
Peter Pilgrim discusses the origins of the Internet and the software develop standards that now are constrained by politics, groups, and egotistical individuals.
Join the DZone community and get the full member experience.Join For Free
Digi-Key Electronics’ Internet of Things (IoT) Resource Center Inspires the Future: Read More
What are technology standards? Essentially, a technology standard is a common agreement on the application programming interface (API) and/or communication protocol in a vertical sector. Standards can be big or small. They have a profound affect on the choices of the software developer community. When technical leaders have to search for new features in a library framework or application server, they will invariably favor the one which has the most standard support over the one, which does not contain it. Technical leaders must balance the continuous flux of technology against the current infrastructure of an enterprise application, any legacy aspects of the software, and the needs of the business.
The British Standard Institute (BSI) mentions three aspects about standards, namely:
- Standards enhance consumer protection and confidence.
- Standards provide a framework of interoperability.
- They facilitate trade.
In this above enumerated list, there is no mention about creativity, entrepreneurship, and that oft-overused-word innovation. Let’s delve into each of these phrases in a later section. For the benefit of people who don’t have time, I want to produce this piece of pseudo language code that represents my own thinking of standards, especially in the Java world.
class Java_Community_Process alias JCP type of Java_Community_Process
This defines an entity called the Java_Community_Process with an alias type. Remember this is not Java programming language but made-up for the example. Of course, my invented pseudo Java language dispenses with semicolons, because I live the second decade of the twentieth first century and not in the mid-1990s. I also bow my head to the concept of delegates, composition over inheritance, and also the idea of class, type, and function versioning, which I have noted in other academic research programming languages. Let’s get back on track.
The JCP is the standards body that maintains, records, and officiate over 500 Java Specification Requests (JSR). Let’s just choose one of them:
abstract class JSR delegate from JCP alias JSR type name Specification // the popular vernacular term "standard" abstract class JPA version 1.0 delegate from JSR abstract class JPA version 2.0 delegate from JSR
This defines the Java Persistence API standard with two different versions:
implementation class Hibernate version 5.0 extends JPA version 2.0 implementation class EclipseLink extends JPA version 2.0 implementation class TopLink extends JPA version 1.0
This defines two standard implementations of JPA 2.0 and acknowledges the existence of an implementation, which complies with the older JPA version.
Normally, when you write concrete class you need to define the super classes first. It is odd practice to write the implementation classes before the ancestor when you have prior knowledge of the full super classes. Once you have lots of implementation super classes and they have common function, collaborators, and responsibility, then you might have this is time to refactor to ease into reuse.
Likewise, before any libraries can be standardised, they ought exist already. There are lots of customers and consumers already using the library consistently, reliably, and productively. This is the reason why it far easier for the expert group create a successful JPA specification first time around than the misery of Entity EJB.
Engineers normally do not focus on future standardization efforts when they are in midst of figuring out fuzzy abstract code and design. Standards tend to be far from your mind, when you and I have a deadline to finish a certain task. Rather, we tend to depend on prior art and the existence of a standard to shortcut our time to finish the code, to get the ticket passed the definition of done, and mark it as “done done."
J2EE Blunders and Musings
When Java EE started in 1999 as J2EE, the committee (the expert group) made technical and commercial strategic blunders in their overall specification.
First, it was XML hell for all sorts of configuration. The first versions of EJB required audacious amount XML configuration, just to define say a Stateless Session Bean. They also specified at least two Java Interfaces that class had to implement. It was a long story, but Java 5 style annotations eventually did save the day.
Second, the expert group designed a disastrous concept called EJB Entity Beans for persistence into database. The expert group based their specification on older design standards such as CORBA.
Third, the expert group and committee was slow to see to developers were moving into ease-of-use, faster and iterative engineering. Application servers were expensive and there were few open source examples of the full J2EE technology available to students and new learners. By the time, of the AJAX and Ruby-on-Rails movement took off in 2005, then the game was almost up. Luckily, Sun Microsystems made some import changes.
Finally, the technology relied heavily on dependency lookup. The committee couldn’t see the future post millennium impact of Inversion of Control vis-à-vis Dependency Injection. Therefore, other people and in particular one individual saw a gap in the market. Some say, that the rest is history.
Around a standard, creativity is related to viability. If a standard appears too restrictive, then history has shown that innovation will happen outside and externally to the group. Some times creativity will follow along the general direction of the API and/or protocol. Sometimes, some vendors will just pay lip service to a standard, because even though it exists, then the standard is just too weak or it just does not support a brand new concept.
Standards, therefore, cannot be used to restrict creativity. However, they can help to ensure interoperability.
Creativity is also a double edge sword, and it can be a reasonable place to add vendor specific APIs to a standard. For example, in Java EE, there are several debatable issues with the standard. I will name just a few debate conversion themes:
Security: The current Java EE security is not adequate enough for many corporate needs and so your mileage does in fact vary. There are several solutions, such as Spring Security, Apache Shiro, and vendor specific APIs. It also worth noting there is no such thing as single-sign on API standard for Java EE.
Embedded Container: There is no standard API for launching for creating a so-called containerless application. Some people called this concept, an uber-jar, or uber-war, and some people call this modularized application server and application. All of the people agree that embedded server inside an application concept turns the conventional deployment of a WAR file to an application server on its head. It is also worth noting that tooling for this concept from major IDE is in its infancy.
Logging: There is a disagreement or rather pleasant no consensus on a logging. There are now many ways to log error messages. Think of logging to a central service in a cloud infrastructure, think of just logging to file, think of logging those customer abandoned the shopping cart analytical data points over to a message queue.
Deployment, Administration and Cloud: There is no consensus on how deploy to a cloud service environment. This is reality even in 2016, because cloud technology is in a fast-pace and in constant flux.
Fig. 1: Illustration about the J2EE design-by-committee decision
Let’s go way back to the beginning of the web. Everyone who works in digital development, design, and architecture, will have heard of Sir Tim Berners-Lee. It was this British gentleman who created the first implementation of the World-Wide Web and designed the XML document variant called Hyper Text Mark-up Language and also the Hypertext Transfer Protocol aka HTTP. Berners-Lee created this WWW, whilst working for a major European scientific concern called CERN. (How ironic that I am bloody writing this text on Friday 1st July 2016?! Note to BREXIT.) We can argue as observers that his former employers CERN paid for Tim’s creativity and vision also the WWW.
Based on the exponential growth WWW in terms of global commerce, trade, and community, the amount of financial currency is enough for CERN to fund scientific research for 2000 years.
Figure 2 depicts the year 2005 when the Java EE 5 and JPA expert groups rejected the design-by-committee philosophy instead chose to standardize over existing multiple implementations including JBoss Hibernate.
According to Wikipedia the definition for IP refers to creation of rights that are granted to protect from commercial competition on intellectual works, which include trademarks, copyrights, patents, industrial design rights, and secrets.
However, just because you take out an IPR, does not mean you cornered the market. Let’s look slight further back in history for an example of this in real world industry.
Way back when Steve Jobs used to wear a bow tie and was suddenly kicked out of Apple Corporation in Cupertino, a little known computer scientist created a novel concept application that was unique to the first editions of Macintosh computers.
Bill Atkinson is a legendary computer programmer and designer. He worked at Apple from 1978 to 1990. He is solely responsible for Quick Draw, a core UI library framework for Macintosh, which marked a landscape change in the field of Graphical User Interfaces. He also created the first example of the library called MacPaint. Bill Atkinson also created HyperCard, which was a stackable precursor to the World-Wide Web. In fact, Berners-Lee used HyperCard as a source of inspiration. The fundamental point with HyperCard was the ability to move from card to card using a click of the mouse on a text element.
The point is that HyperCard, although a precursor to WWW and to what we know, was a commercial application, because consumers paid out of their hard-earned cash for the privilege of using it. There were no freemium or or hardly any “lite version” of commercial products available in the year 1987. No one had even heard for this marketing Meme, because there was no need. We were living in the world, those of us, who can remember and who were alive at this point, could not see the point of this business model. We were relying on cassette tapes, floppy disks, and there if you had access to connected network it was called the Ethernet, and it was probably named the Token Ring.
What Berners-Lee did do with his baby, the WWW? Because he worked at CERN and he believed himself in the scientific model of common access to information, and because he want to help his user experience (UX) end users, the respected and very hard working scientist, he opened up his baby. Not for free, but passed the IPR of the WWW to the existing technology standards body at the time. Sir Tim, first, supplied the Internet Engineering Task Force (a 30-year body) with the HTTP document for the communication. Second, in 1994 he help found the World Wide-Web Consortium (W3C) to officially mandate the HTML standard and other parts to do with the Web. W3C is a recognised standards body.
So yeah! Without this grant of the IPR to the organisations, the standard bodies, our view of the world would have look very different to the digital world that we live today.
With standards body, therefore IP is granted, authorised and preserved.
However, this is not the end of entrepreneurship story or up to now, how to grant a gift of technology and creativity to a standards body. Acting as a safe house from industrial disruption, standard bodies can provide a benefit protection from hostilities.
Everybody over the age of 30 probably remembers their initial impressions of the Netscape web browser, the rightful ancestor to Mozilla Firefox. Netscape browser was the product of a certain Marc Andreessen in 1995 and it also exploited a gap in the market and opportunity, the two major ingredients in business. Public access to the Internet suddenly became a thing for the white wine, chatter and gossip classes and also there was no commercial web browser apart from the very academic and pedestrian looking NCSA web browser.
Entrepreneurship and standards may not appear to go hand in hand, because they look like polar opposites on a magnet. Yet, businesses would function abnormally without guarantees and certain incentives to shorten the time-to-market, the ability to recruit qualified personnel, and expand in to new territories. Standards are therefore smart thinking—you just have to separate your crown jewel IPR from the ones that contribute to the software technology community. Think of it as pay back some quanta of resources back to the those people that help make you rich in the very first place!
Finally, let’s move on to the subject of innovation.
Innovation is a lost soul of a word. What does it actually mean to innovate? How is it different from creativity?
In my mind, innovation means find novel interpretations of certain observable events. Innovation is pure thinking without distraction. Innovation is sometimes realises that two conflicting ideas or apparently separate themes, topics, or subject matters are actual associated. Quality innovation feels like flying high of the planet and seeing outside the status quo, but also realising the detail. Sometimes it is the reverse that it is true. True innovation is scientific thinking like cosmology, Linde’s multi universes, or along those levels.
In software, we don’t necessarily look at innovation. The best we have seen in C.A.R. has been Hoare, QuickSort, as an algorithm or expressed as CAP thereom. These are algorithms. Unfortunately, you cannot just sell algorithms with RSA encryption and cryptographic physical cards like the Oystercard, which is the exception to the rule.
However, we can innovate in software products, libraries, and frameworks. The point is that innovation works best outside of a standard body and ahead of any attempt to standardize a solution. However, software innovation should stand on the shoulders of giants. We have this idea of NON-INVENTED HERE (NIH) or DO NOT REPEAT YOURSELF (DRY) that fills the entire industry like a horrendous disaster. If you're writing your own transaction service from scratch or attempting to rewrite an operating system, then you need to be quite exceptional talented and hard working. Linus Torvalds takes a bow. Innovation takes place through need, frustration, and endeavour.
Figure 3. Strong standardization model depicts the political power emanating from the entrepreneur, who marshals the amount creativity. Think of “herding cats." Note: Any innovation that eventually affects the standard generally has a small sweet spot, which I call the grand ideal.
When we have at least two similar implementations of a Java EE innovation then perhaps, and only then, should we think about organising a JSR for it, otherwise we would be making the same blunders as J2EE 1.0. The trouble with innovation is that it is always in a state of flux—how do you know that you innovated in a particular space? When is your solution stable enough? Are you comfortable sharing your IPR with your competition? How will it affect your customers, prosumers and your core business model? If you run a business then you need to know the answers to all of these questions. It probably is very understandable why so few businesses get involved in any sort of standards body process, because of the overall time, effort, and energy to contribute. If you worked on a standardisation tasks, you would definitely enquire about the most likely return on investment. This tension between between innovation, profit and loss, and being a good citizen in a standards body will never be easy to solve.
Figure 4. Weak standardisation model depicts the political power emanating from the creativity, which supercedes the original and any subsequent entrepreneurs. Such an arrangement potentially leads to eventful dissolution of the standard, because the participants will disagree so much about who has the best creative direction. The innovation sweet spot is rather tiny here. This is to be expected.
People manage standard bodies. People are involved in politics and policy. Therefore, standard bodies are political even though the remit of many is to reduce the amount friction between egotistical individual, companies, and groups. Overall, they cannot function without general communication and agreement. The best software standard bodies have diverse communal function and avoid social dysfunction and they facilitate the vertical sector, libraries, and technology. Take the W3C: The founder and still current director Sir Tim Berners-Lee acts a solid vector of positivity in order to lead the world in the future of the web. He alone embraces this vision of a beneficial actor and is the face of the standard, rather than a faceless C-level executive operation in a distant unattainable unaccountable concern.
It should be clear by now you cannot use a standards body or expert group to innovate. Do not expect, therefore, to see innovation in Java EE expert group (or any other standards body: ECMA, W3C, IETF) anytime soon, because the actual inventors, creators, and digital bods are not actually thinking about standards body when the light bulb in their heads suddenly emits brilliantly light. They are far too busy racing ahead to be the first to get that innovative product out of the door into consumer hands. Only when they are finished, will they look back along their trajectory and historical journey and realize, perhaps, they should have standardized parts of their intellectual property.
The Java Community Process is a standard body for Java technology, not innovation. From the purist point of view, some may say that the JCP is just biased, because Oracle supports it, financially, politically, and socially; and because Oracle is the current steward of the whole Java platform. In my view, JCP can hold it own, because it has set processes and by-laws separate to Oracle. Also external companies, blueprint concerns, such as IBM, Red Hat, Azul and others have contributed representatives to defining Java Specification Requests. Therefore Oracle is answerable to community through the JCP and also through consuming the products and services of these associated businesses. Developers have their own power, believe it or not. If you want to shout out disapproval about the Java EE 8 progress, then you should look at the Java EE Guardians and then decide to sign their Petition.
Published at DZone with permission of Peter Pilgrim , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.