In its ongoing effort to make its workings as transparent as possible, the Executive Committee (EC) of the Java Community Process (JCP) publishes the minutes of its meetings. The Aug. 9 minutes are online now, and though these kinds of documents tend to provide reliably dry reading, this one proved to be a real page turner for anyone interested in the future of Java EE. (Or would have been if it were, you know, printed on paper.)
A couple of things caught my eye: Anil Gaur, Oracle group vice president with responsibility for Java EE and WebLogic Server, reportedly gave a short presentation on Oracle's Java EE strategy. As recorded in the minutes, he talked about how enterprise programming styles are changing to focus on apps deployed in the Cloud via modular runtimes, and how "we," by which I'm presuming he meant Oracle, would like the future of Java EE to be "viable to the next generation of applications."
Elsewhere in the minutes, JCP Chair Patrick Curran reportedly talked about a meeting he'd had with Oracle execs "on the subject of relations between OpenJDK and the JCP." Curran reported that Mark Reinhold, chief architect of Oracle's Java Platform Group, "had argued that much of the process required by the JCP was duplicative and unnecessary, and that Mark had even suggested that Expert Groups added little value to OpenJDK's existing processes."
We've been hearing predictions like Gaur's that the future of enterprise Java is in the cloud for a while now, and I continue to hear about the uncertain future of the JCP. But felt the need for some elaboration, so I reached out to some Java EE mavens to see what they had to say.
EC member and London Java User Group leader Martijn Verburg attended that meeting (virtually). "I think Anil is echoing the overall market trend for cloud based applications and services, with a subset of that trend being microservices and serverless," he told me via e-mail. "That is, less and less applications will be developed for on premise, requiring the sort of transactions support and connectivity with traditional on-premise systems. For example, with today's Java EE you have standards for Batch processing, transactions, persistent messaging with JMS and so forth.... So that means Java EE needs to evolve and produce standards around service discovery, configuration, logging, JSON processing, and binding, etc., and be less about heavyweight messaging, transactions and so forth."
On the subject of the future of the JCP, he added that he expects it to be "alive and well for some time yet."
"I think the community at large wants to see standards around Java in order to make long terms plans based on the technology," he said, "so the JCP should remain, or some other standardization effort would, I think, naturally take its place."
I also heard from Mike Milinkovich, executive director of the Eclipse Foundation, another EC member listed among the attendees. "Java EE was originally designed for on-premise IT infrastructure," he said. "As more IT moves to public and private cloud infrastructures, Java EE needs to change. Enabling Java to support multi-vendor standards for elastic scalability and DevOps-style deployment models will be key to its future success."
He, too, felt the JCP had a few miles left on it. "I don't think the JCP is going anywhere," he said. "Open source is great, but OpenJDK only provides a single implementation. The team there is effectively building a single product, not a multi-vendor standard and an ecosystem. That may be inconvenient for some Java platform developers, but I am confident that Oracle's executive management understands how important the JCP is to the success of Java as a platform. Without the JCP there could be no WebSphere or JBoss or J9 or Zulu."
EC member Werner Keil, also on hand for the meeting, acknowledge the shift of Java EE 8 toward the Cloud, but argued that that change is not necessarily based on Oracle's recent interests. "Several members of the Java EE Umbrella [Expert Group] repeatedly asked for better support of what once was called 'multitenancy' (aka being able to serve multiple clients/tenants in the cloud more easily)," he said via e-mail. "It took until the Java EE 8 release train (or even beyond) to get those voices heard. Well, it also took till Java SE 8 to get lambdas and 9 to get modularity, first intended at least for Java SE 7."
On the JCP vs. OpenJDK question, Keil said: "Despite the 'Open' in its name, OpenJDK isn't more open than the Open Handset Alliance or .NET Foundation, while the JCP… is a vendor-neutral industry body…. To [paraphrase] Orwell, Oracle isn't 'more equal' than others in the JCP, while they're a lot more equal in OpenJDK. Not everything is rosy and efficient there, either. For example: Project Kona was announced during a BOF last year at JavaOne, and yet, as you can see from its repository, there has been no activity since before JavaOne, and some parts are even inactive for almost two years now."
I also touched base with Josh Juneau, a Chicago-based app developer, blogger and author. He wasn't at the EC meeting, but he's a thoughtful industry watcher who, like me, could read the minutes.
"The foundation of the JCP relies upon the community-centric approach that involves many different voices, and not just those of the big players," he said in an e-mail. "The community, including vendors, developers, and user groups alike, need to have the ability to help steer the direction of enterprise Java, because there are so many different pieces to the enterprise puzzle. One company cannot have all of the answers in this space, so if the JCP were taken out of the decision making and the evolution of Java EE in the future, I feel that it would make Java EE a less healthy platform for development. It would force the vendors and developers to change the way they did business based upon one company's idea of what the enterprise should look like. However, if Mark's statement was not addressing the removal of the JCP process, but rather a revision, then I could understand his position a bit more. Perhaps Mark has different ideas for how the process should be executed. That said, we need the JCP in place, whether in its current form or in a revised format, where the community still has just as much influence."
Surely everyone who reads this blog knows that the JCP is the group that certifies Java specifications, and the EC is charged with guiding "the evolution of Java." What might not be such common knowledge -- and what I want to acknowledge here -- is how hard the JCP has been working since Oracle acquired Sun Microsystems and took over the stewardship of Java to rework some of its knottier components. It started in late 2013 with Java Specification Request (JSR) 348, which was all about transparency, participation, agility, and governance. That JSR was approved without much fuss, and a year later, the JCP sought to merge two ECs -- the Java SE/Java EE committee and the ME committee -- under JSR 355. That plan was also approved.
Posted by John K. Waters on 08/24/2016 at 10:18 AM0 comments
In an earlier post I wrote about a new independent effort to support Enterprise Java, the MicroProfile.io project, which aims to create a baseline platform definition that optimizes Java EE for microservices architecture. I connected this week with Martijn Verburg, co-leader of the London Java Users Group (LJC), one of the initiative's founding organizations, to get some additional details on the project. Verburg is also the CEO of jClarity and a very knowledgeable Java maven.
(He lives in the UK and I'm in Silicon Valley, so our conversation took place over e-mail.)
JKW: The MicroProfile.io initiative is also sponsored by Red Hat, IBM, Payara and Tomitribe. How did these organizations come together?
Verburg: There has always been collaboration among these vendors on various open-source software projects, in particular around Java EE. For the MicroProfile initiative they'd been having separate discussions for two to three months leading up to the announcement. The first discussion was around the future of Enterprise Java and how it needed to adapt to the new world of Microservices, Cloud native and reactive, without losing the longevity, interoperability, and standards that the marketplace was used to having.
The second discussion was around the lack of progress on several key Java EE 8 specifications (about six to nine months of no movement from Oracle as it was figuring out its internal strategy for Java in this space). The LJC was involved in those early discussions, representing the Enterprise Java developer community and their myriad needs and wants.
(When I say "Enterprise Java developer," I broadly mean engineers that work primarily with some set of Java EE components at the core of their applications, such as Servlet or JAX-RS.)
JKW: Why is the project necessary?
Verburg: As a group we decided that there needed to be stronger and faster collaboration for working on new APIs and implementations that would make this new world of Microservices accessible to millions of Enterprise Java developers. It was important that this collaboration happened pre standardization, as it needed to be fast, throw away bad ideas, and provide the freedom to try new ideas! This is so that we can validate these ideas amongst the vendors and amongst the developers that will be using these new APIs.
JKW: The project goal of creating a baseline platform definition that optimizes Enterprise Java the for microservices architecture is pretty clear. Is there anything else you'd like to say about that?
Verburg: That [the initiative] is very much a partnership between the developer community and the vendors. In fact, I'd even say that it's leaning toward a relationship in which the developers are expressing their requirements in this space and the vendors are responding by rapidly prototyping ideas and getting feedback and refinement from the community.
JKW: Will the initiative become a JSR in the Java Community Process or an Oracle JEP, or is that even necessary?
Verburg: We'd like to see parts of the platform go through a standardization effort (when ready), yes. I guess you could see it as an incubator for potential standardization work. It's something that the JCP has actually always encouraged; they like to see multiple implementations of a technology, with a baseline of those competing implementations being standardized.
JKW: Have you all thought about how you'll manage the project -- organizational governance, that sort of thing?
Verburg: There's a mailing list thread that started today about the potential move to a Software Foundation. All of the partners agree that it would be a good step for the initiative and would help enshrine its neutrality and collaboration.
JKW: MicroProfile.io seems likely to put even more pressure on Oracle to pay attention to Java EE. Am I right about that? Have you heard anything from Oracle about the project?
Verburg: Oracle have started to shed some light on some of their ideas around this area, and we've invited them to join in the effort. They recently stated at the JCP EC meeting (minutes to be released shortly) that they'll look into doing that, as well as making their plans on Java EE 8 clearer going forward. We find that encouraging.
Posted by John K. Waters on 08/12/2016 at 1:27 PM0 comments
Oracle may have been neglecting Enterprise Java over the past few years, but it's sure paying attention now. The Java EE Guardians threw a spotlight on what they saw as a lack of core investments in the technology when the volunteer advocacy group went public in March, and they cranked up the intensity when they posted a petition on the change.org Web site aimed at Oracle executives. In July, Oracle seemed to be responding to the Guardians' charges in a statement about its commitment to Java EE 8, and a growing number of Oracle execs are actually talking to the press.
Now comes a new independent effort to support Enterprise Java: the MicroProfile.io project. Sponsored by Red Hat, IBM, Payara, Tomitribe and the London Java Community, the goal of the project is to create a baseline platform definition that optimizes Enterprise Java for microservices architecture.
"Enterprise Java technologies like Java EE have evolved with the industry for nearly two decades to support distributed application architectures based on RMI/IIOP, Web Services, and REST," the Web site explains. "The MicroProfile is the next step in that evolution."
Project contributor Antonio Goncalves, a Paris-based Java EE developer and architect, agrees that the MicroProfile represents another step in the evolution of Java EE, whose origins he traces to the Enterprise JavaBeans component model. "The EJB component model was a Micro component," he wrote in a blog post, "just embed the needed business code, as small as you can, package it as a unit in a single jar, link it with other components/EJBs via RMI/IIOP, and the container will look after the rest.... But since then, Java EE containers have evolved. They have been lighter, smaller, faster ... so it was time to have a MicroProfile: micro components running in a micro container."
The project is focused initially on providing a baseline for a group of specifications: JAX-RS, the Java API for RESTful Web Services, Contexts and Dependency Injection (CDI) and JSON-P (JSON "with padding"). The project's organizers are aiming to release a public version in September.
"We want to ensure, as we move forward into this new, containerized, cloud-native world, that we do it responsibly, and customers don't get left with some proprietary single vendor technology stack," said Rich Sharples, Red Hat's senior director of product management during an interview following the announcement of the project at the recent Red Hat Summit.
The project's organizers are emphasizing the need for community participation in developing the MicroProfile definition and project roadmap. "I think there's a real chance that we can bring the whole Enterprise Java community together around this," Sharples said.
Posted by John K. Waters on 08/10/2016 at 6:29 AM0 comments
Reddit's "Ask Me Anything" (AMA) forum has attracted some brave souls since the "I Am A" (IAmA) subreddit was established in 2009. Everyone from Snoop Dog to Donald Trump (set to host an AMA on July 27) has signed up for this unique, almost-anything-goes public Q&A. Last week Google's Android engineering team took the AMA plunge for the first time, just a few days after the release of the fifth and final developer preview of Android Nougat (v7.0).
My colleague, David Ramel, covered the event and pointed out to me the flood of questions about Java.
Android applications are developed in Java, so the high level of interest wasn't surprising. But we live in a polyglot world, and many of the questions about Java were actually about how (and whether) the Android team will support other languages in the future. A question from "mastroDani" was typical:
Java is a good programming language but [its] age is starting to feel, a modern language would make the development easier and faster. The community is creating many unofficial language supports for developing in Android: kotlin, groovy, scala, just to name a few. This shows there's a request for it. However, choosing one of those language comes with some level of risk or unexpected side effects because of its unofficial support. Is any of those language gonna become officially supported? Or is there any plan to move from Java to something else?
Anwar Ghuloum, engineering director for the Android Core Platform group, fielded that question: "We don't have any plans to move to a new language. Java has a lot of advantages to it and the versions 8, 9, and 10 have some pretty interesting stuff for developers. We are planning to track more closely in time to the Java language standard...."
Another questioner, "elkaramba," also wondered if the team might be at least considering support for Kotlin, a statically typed language similar to Scala developed by JetBrains. The question prompted a lively exchange among several participants. mastroDani observed: "Look at how many question [have] been asked about it. Someone even suggested we should use Swift to develop Android apps. I would be really surprised if Google kept ignoring all those voices and I don't want to jump on a language risking having to change it again in a few years."
Later "Inkprk114" brought the conversation back to the question of Android support for Kotlin: "... I personally doubt that Google will officially endorse any other language for a long while, but I would like to know how your team feels about some of the alternative languages that are popping up -- Kotlin being the one I'm most interested in. Do you feel it's in stable enough condition to use for production applications? Would you recommend using other languages, or do you feel sticking with Java is still the correct decision for developers? Have there been any discussions regarding Kotlin on the team, and are you guys in touch with any of the developers of the language over at Jebrains?"
Ghuloum's response: "We don't have any plans to officially support a new language in Android, so we'd encourage folks to continue to use Java :) That said, you should continue to use what works for you."
mastroDani wrapped up the discussion with this observation: "The community is creating many unofficial language supports for developing in Android: kotlin, groovy, scala, just to name a few. I believe the reason behind this is that those language [make] writing software easier, less tedious and more boilerplate-free. However, choosing one of those language comes with some level of risk or unexpected side effects because of [Google's lack of support].... "
It's clear from this conversation (which you'll want to read in its entirety) that Google is solidly wed to Java on Android and has no plans at the moment to support anything else. That's not surprising, either; the company has invested a lot in Java (in court costs alone). And earlier this year Google announced plans to replace its Apache Harmony implementation of the Java libraries in upcoming versions of the Android OS with Oracle's OpenJDK, effectively replacing the code that has been at issue in the long-standing legal dispute between the two companies.
I'm sure it's useful to a get clear, from-the-horse's-mouth answer to this question for Android developers, a growing number of whom are very interested in Kotlin, Groovy and Scala, "just to name a few." How long the company will be able to stick with this monolingual strategy remains to be seen.
Posted by John K. Waters on 07/26/2016 at 2:30 PM0 comments
Sonatype has just released its second annual report on managing open source components. The "2016 State of the Software Supply Chain" report is available now, and well worth reading.
Among the things I like about this report is that it's based on the analysis of 31 billion download requests of open source software components from the Central Repository, which Sonatype manages, and that it's the result of an analysis of the patterns and practices of more than 25,000 developers and 3,000 organizations.
The company started out as a core contributor to the Apache Maven project, which is now the largest public repository of open source Java components. That 31 billion figure represents an increase of 82 percent between 2014 and 2015, according to the company. Sonatype also introduced repository managers into the software supply chain with its Nexus products.
Easily the most disturbing revelation in this report is that defective components in the software supply chain are routinely making their way into applications, which is costing enterprises millions of dollars. In fact, 1 in 16 downloads from the repository had a known security defect, the report's authors found, and 6.8 percent of components in use among the 25,000 applications analyzed had a known security defect.
And it gets worse: "However, because a single component may contain multiple vulnerabilities, it's important to understand that an average application consisting of 106 components -- of which 6.8% are known bad -- could contain numerous unique vulnerabilities," the report stated.
The problem here is twofold: not all components are created equal -- as the report puts it, the "massive variety and volume of software components vary widely in terms of quality -- and components "age and grow stale quickly."
"Last year, the average enterprise downloaded 229,000 open source components," the report warned. "If properly sourced and managed, open source components are a tremendous source of energy for accelerating innovation. If not, they lead directly to security vulnerabilities, licensing risks, enormous rework, and waste."
I touched base about this particular finding via e-mail with John Matthew Holt, founder and CTO of Dublin-based Java security vendor Waratek.
"That's an overwhelming statistic when you consider that it represents about 2 billion components downloaded with a known vulnerability," he said. "Security risks are a fact of life and will always be with us in some form. What this statistic points to is the need to move beyond trying to 'fix the code' or 'just writing better code.' Those are not viable solutions to address all vulnerabilities."
Holt is an enthusiastic proponent of Runtime Application Self Protection (RASP), which Gartner has defined as "a security technology built in or linked to an application or app runtime environment, and capable of controlling app execution and detecting and preventing real-time attacks." Holt's company makes a containerized RASP product, called Locker, which provides security monitoring, policy enforcement, and attack blocking from within the Java Virtual Machine (JVM).
"The Sonatype report points to two major Java risks that can be mitigated by RASP delivered by virtualization: known (and unknown vulnerabilities) as well as legacy code," he said. "A RASP solution can virtually patch known vulnerabilities on a permanent basis or temporarily while you rewrite the risky code, without shutting down the app. RASP can also be used to bring out-of-date components, whether they represent a vulnerability or not, to current Java standards without having to change an app's code. That's important when you look at the Sonatype's finding that 10% of components in 1,000 repositories had not been updated in five years or longer."
I also wondered about the implications of these findings for Java SE 9 and Jigsaw (componentization), due later this year.
"There are problems throughout the entire app stack today," he said, "not just with components downloaded from repositories. You'll find problems in the business logic layer, open source components from libraries, and even the code that comes with the JVM platform. So in that sense, a new version of Java and Jigsaw won't expand the problem; they will only add more hay to the stack while we search for needles of vulnerability."
The Sonatype report looked at more than security vulnerabilities, of course. Its other key findings include:
- Developers are "gorging" on an ever expanding supply of open source components. The use of third-party, open-source components "exploded" last year, the report found, and the trend is accelerating.
- "Vast networks" of open source component suppliers are growing rapidly. These networks created 1,000 new projects and delivered 10,00 new versions per day, according to the report.
- Software supply chain management practices are gaining traction. Top performing enterprises, federal regulators, and industry associations have embraced the latest supply chain management best practices, which include things like using fewer and better component suppliers, procuring only the best parts from those suppliers, and continuously tracking and tracing the precise location of every component.
There's much more in this report, including tons of stats and some useful infographics. As far as I'm concerned, it's a must read.
Posted by John K. Waters on 07/13/2016 at 1:11 PM0 comments
Oracle has finally responded to my -- and I'm sure many others' -- requests for comment on the future of Java EE, on which the formation of the Java EE Guardians threw a spotlight a few months ago. A member of the Oracle PR team sent me an e-mail in which Mike Moeller, Oracle's vice president of marketing communications and global public relations, offered the following:
"Oracle is committed to Java and has a very well-defined proposal for the next version of the Java EE specification -- Java EE8 -- that will support developers as they seek to build new applications that are designed using micro-services on large-scale distributed computing and container-based environments on the cloud. Oracle is working closely with key partners in the Java community to finalize the proposal and will share the full details with the broader Java community at JavaOne in September."
The Guardians, a group of volunteers committed to supporting enterprise Java, has been making the case that Oracle has been "conspicuously neglecting" Java EE. I've been reaching out to Oracle for a reaction to that claim since the Guardians made its public debut in March, but it's been radio silence from the blue silos in Redwood Shores until now.
It would be easy to conclude that that silence was broken in response to a petition posted by the Guardians last month calling for Oracle "to cooperate with us as a responsible, community-focused steward to move Java EE forward." (More on the petition here).
According to Reza Rahman, a former Oracle enterprise Java evangelist and one of the founders of the Java EE Guardians, response to the petition has been strong and "is proving instrumental in getting Oracle to listen." More than 2,800 people have signed the petition so far, Rahman told me in an e-mail, and more are signing at an average rate of 20 to 25 per day.
"For a deeply technical issue, I think that's a very good response rate," he said. "Most technical surveys usually garner around 500-1,000 input points (and struggle even to get that). It is certainly enough to empower our allies within Oracle to renew the struggle to do the right thing for the community."
Although the Moeller quote is short on details, Oracle's response should be viewed as a positive development, Rahman said. "The community should treat the lack of detail as an opportunity to continue to constructively engage Oracle, while remaining vigilant," he said. "We all need to work together to continue to ensure the well-being of the Java and Java EE ecosystems. Hopefully the forward plans for Java EE will be developed collaboratively and with direct community input."
Rahman also reminded me that the Guardians has been attracting some high-profile support to its cause. The growing list of community movers and shakers that have joined the group now includes James Gosling (the father of Java) and Java User Groups from all over the world.
Posted by John K. Waters on 07/08/2016 at 11:56 AM0 comments
The Java EE Guardians launched their public Web site last week and simultaneously posted a petition on the change.org Web site aimed at Oracle executives.
The original core group of volunteers committed to securing the continuing evolution of enterprise Java founded the formal organization in March with a Google Group and a Twitter handle (@javaee_guardians). But the Web site provides what founding member Reza Rahman calls "the essential public face of our movement."
"It makes us public in a way that the Google Group and Twitter account do not," Rahman told me in an e-mail. "It basically gives our movement identity, structure and presence. It says, we are here, we are serious and we are persistent."
The Web site includes a home page that explains the group's purpose, an "Evidence" page that makes their case that Oracle is neglecting Java EE, a page that tracks the group's activities, and one that lists its growing membership, which currently includes James Gosling (the Father of Java) and Java User Groups from all over the world.
The Web site also links to the change.org petition page, which Rahman said the Guardians posted to provide a wider range of people who might be interested in this issue with a place to take some action. "It's a way to empower average people and engage them with our movement," he said.
The title of the petition reads: "Tell Oracle to Move Forward Java EE as a Critical Part of the Global IT Industry," and it's directed specifically at Oracle Executive Chairman and CTO Larry Ellison, co-CEOs Safra Catz and Mark Hurd, president of Product Development Thomas Kurian, EVP of Fusion Middleware Development Inderjeet Singh, and Group VP of the Microservices-Cloud group Anil Gaur.
The document lays out the case again that "Java EE is incredibly important to the long term health of the entire Java ecosystem," and that "Oracle is conspicuously neglecting" it. And it asks visitors to the site to sign up to petition Oracle to do three things:
- Clarify how it intends to preserve the best interests of the Java, Java EE, and servers-side computing ecosystems.
- Commit to delivering Java EE 8 in time with a reasonable feature set that satisfies the needs of the community and the industry.
- Effectively cooperate with the community and other vendors to either accept contributions or transfer ownership of Java EE 8 work.
"As committed as we are," the document states, "we still need Oracle to cooperate with us as a responsible, community focused steward to move Java EE forward."
Shortly after the Web site and petition went up, I chatted via e-mail with one of my favorite industry watchers about the Java EE Guardians and their efforts. Forrester principal analyst Jeffrey S. Hammond believes that they are sincere in their efforts, but also that, despite those efforts, the future of Java EE is uncertain.
What about the charge that Oracle is neglecting enterprise Java?
Posted by John K. Waters on 06/22/2016 at 10:18 AM0 comments
Apple announced the first Developer Preview of Swift 3.0 at its annual Worldwide Developer Conference in San Francisco (WWDC) this week, marking the next phase in the rapid evolution of this increasingly popular open-source programming language. The growth of the Swift ecosystem among third-party developers is something of a phenomenon, and IBM appears to be leading that burgeoning pack.
Since Apple released the language to open source last December, Big Blue has become one of the largest users of Swift for mobile app development. It was the first cloud provider to enable the development of applications in native Swift. The company likes to say it was "first to the table" with Apple to bring Swift to the enterprise. "We jumped in full-force in December," said John Ponzo, an IBM fellow and vice president and CTO of IBM's MobileFirst group. "We saw the potential right away to move this out to the server. We were all in right away."
To date, IBM has built more than 100 enterprise applications using Swift, and it has developed a range of tools for the language -- things like the newly announced IBM Cloud Tools for Swift (ICT), which is aimed at developers creating Swift apps "that span both client and server-side code." ICT is a Mac app designed to simplify the management and deployment of server-side assets, Ponzo explained. It allows developers to group client-side and server-side code written in Swift, deploy the server-side code to IBM's Bluemix cloud platform, and then manage projects using ICT.
Ponzo also pointed to the success of IBM's Swift Sandbox, a cloud environment that allows devs to write Swift code and execute it in a server environment on top of Linux. Each sandbox runs on IBM Cloud in a Docker container.
The company claims more than 1.5 million code runs on the Sandbox, up 200 percent since February.
IBM also announced Swift 3.0 beta on LinuxONE, IBM's Linux-based mainframe servers. Developers are now able to use Swift on LinuxONE, Ponzo said. The company plans to have a production-ready release when Swift 3.0 goes GA.
IBM sees great potential in Swift on the server side, Ponzo said. The company has been focusing its efforts on maturing the language at the backend and adding "first-class support" in the cloud. "This is really about addressing the key issues that enterprise developers are having," he said. "Swift has this combination of scripting-language-like syntax with a core systems language, and we're looking at how it can help developers who are building the next generation of cloud-based workloads. We'd like to make Swift a very big part of how those next generation services are built."
Big Blue also claims more than 1,500 client and server-side packages on the IBM Swift Package Catalog (up 400 percent since February), and more than 100 apps across 14 industries built on the IBM MobileFirst for iOS solution, which combines IBM's data and analytics with Apple's consumer experience.
Back in February, IBM introduced Kitura, an open source Web framework, written in Swift, that enables both the mobile front-end and back-end portions of an application to be written in the same language.
Launched at the 2014 WWDC, Swift is the successor to Apple's Objective-C. It sheds the "baggage of Objective-C," the company said at the time, to provide "an innovative new way of coding for Cocoa and Cocoa Touch." Where Objective-C relied on defined pointers, the Swift compiler infers the variable type. But it kept such features as well-defined namespaces, generics and operator overloading.
Posted by John K. Waters on 06/15/2016 at 1:52 PM0 comments
Hewlett Packard Enterprise (HPE) is inviting open source developers to write and contribute code to The Machine project, an effort to juice up its ambitious plan to reinvent computing. During my reporting on that news I had the opportunity to talk with a real veteran of the Open Source Wars. (Not officially a thing, I know, but it should be.)
Bdale Garbee, HPE Fellow and Office of the CTO at Hewlett Packard Labs, has been involved with open source software professionally since the early 1990s. He was one of the first Debian developers, and set up the original developer machine for that open source OS in 1995. Garbee said he actually made his first contribution to what would later be called free and open source software (FOSS) in 1979. He has been continuously involved ever since.
Garbee had been working at HP for 26 years when he took early retirement from his job as Chief Technologist for Linux and Open Source in 2012. He was called out of retirement in late 2014 by Martin Fink, EVP, CTO and Director of Hewlett Packard Labs. Garbee agreed to come back and help with The Machine in no small part because of Fink's reputation as an exec who gets open source.
"He twisted my arm to come back, because he saw that there was an opportunity to grow the company's open-source strategy into a major pillar of its general technology, development, and evolution strategy," Garbee said. "We're now working with others inside the company, thinking about our future technology roadmap and our development activities as an opportunity to be more open and collaborative by default."
Of course, nowadays everybody gets open source. During one of his first conference keynotes, Microsoft's newish CEO, Satya Nadella, famously declared "Microsoft loves Linux!" But HPE opened The Machine much earlier in that project's lifecycle than is typical, and Garbee expects that to happen more often at HPE. And HP has been involved in the open source world for decades, chiefly around the Linux kernel, but also as a big contributor to OpenStack and other projects.
"Somewhere between the time I took early retirement and when Martin brought me back, we turned a corner," Garbee said. "It's just different today. I'm no longer beating on people's doors to get them to open up and listen. It's very much the other way around. It's no longer a question of whether open source is a good idea. It's all about finding the right way to structure the work and build communities of interest around the pieces of technology and the work that are most interesting to us."
"I've had this conversation with some of my peers in the industry who have also been involved with free and open source for a very long time, where we look at each other and say, 'Oh my god, we won! Now what?'" Garbee added. "It's immensely satisfying, but the stress level does go up a bit. We've convinced everybody that these are good ideas. We've shown the world that you can run successful businesses around this model of collaborative development. HPE is making what amount to company sized bets on doing things this way. We definitely have to deliver. We have to make it all work."
BTW: "Bdale" is a non-punctuated contraction of "Barksdale," Garbee told me, which was his maternal grandfather's last name. His full name: Alfred Dickenson Barksdale Garbee II.
Posted by John K. Waters on 06/13/2016 at 4:43 AM0 comments