Typesafe this month marked the five-year anniversary of Akka, its open-source run-time toolkit for concurrency and scalability on the Java Virtual Machine (JVM).
Written in Scala and used to build highly scalable, fault-tolerant applications in both Scala and Java, Akka has gained serious traction since Swedish programmer Jonas Bonér pushed out the first public release (v.05) on July 12th, 2009. The company now includes some big names on its Akka user list, including Amazon, BBC, Cisco, Credit Suisse, eBay and more.
Bonér, who is Typesafe's CTO and co-founder, had worked for years building compilers, runtimes, and open source frameworks for distributed apps. Somewhere along the way, he says, he became "fed up" with the scale and resilience limitations of CORBA, RPC, XA, EJBs, SOA, and the Web Services standards and abstraction techniques Java developers typically used.
"It started to dawn on me that it wasn't that we were using the wrong tools," Bonér told ADTmag. "It was a fundamentally wrong approach to building software."
A better approach, Bonér concluded after "tinkering" with the Oz and Erlang languages, was the Actor Model, which utilizes objects that encapsulate state and behavior. Each actor also has a mailbox, and communicates exclusively by exchanging messages placed into a recipient's mailbox. This model provides a unified, single abstraction over concurrency and distributed computing. And an Actor's behavior can be redefined at runtime.
"I found the Actor Model to be a really good basis for building this next generation middleware," Bonér said. "And I could see that we needed to bring them over to the JVM."
Akka is one of the technologies emerging around the concept of reactive applications, described in "The Reactive Manifesto" as apps that better meet the "contemporary challenges of software development," in a world in which applications are deployed to everything from mobile devices to cloud-based clusters running thousands of multicore processors. Bonér wrote the first version of manifesto, which defines the four "critical traits" of reactive apps: event-driven, scalable, resilient, and responsive. By embracing these traits, the manifesto asserts, developers produce apps that are highly responsive to user experiences, provide a real-time feel, and are backed by a "scalable and resilient application stack" that can be deployed just about anywhere. A number of others contributed to later drafts of that manifesto, including Typesafe's other co-founder, Martin Odersky, who created the Scala language. That list of contributors also includes Erik Meijer, Greg Young, Martin Thompson, Roland Kuhn, James Ward, and Guillaume Bort. Since it was published, hundreds have "signed" the manifesto.
Odersky created Scala, a general purpose, multi-paradigm language that runs on the JVM, to integrate features of object-oriented programming and functional programming. Typesafe is also responsible for the Play Web app framework, a development and runtime environment billed as "a clean alternative to legacy Enterprise Java stacks." Play compiles Java and Scala sources directly and "hot reloads" them into the JVM.
In 2013 Typesafe acquired of Spray.io, a suite of lightweight Scala libraries that provide client- and server-side REST/HTTP support on top of Akka. The company hoped to broaden the appeal of the Typesafe Platform to Java developers with "one of the best performing REST/HTTP libraries in the Java ecosystem," Boner said.
The Akka team, which now comprises six members ("It's a good size," Boner said), shipped version 2.2 in July 2013. That release included full support for clustering. In October of that year, the team introduced Akka Persistence to allow stateful actors to recover from JVM crashes "in a way that Actors themselves are persisted in memory," the company explained. In April 2014, Typesafe unveiled early preview releases of two projects designed to improve data streaming on the JVM: Akka Streams and Reactive Streams (ADTmag coverage here).
Typesafe has posted an infographic of the history of Akka that shows its evolution, the influence of Scala Actors on its development, the Oz/Erlang connection, the emergence of the Akka Persistence module, and all the creative people involved—not to mention how it got its name. (Hint: It's not an acronym.)
Posted by John K. Waters on 07/14/2014 at 9:16 AM0 comments
The annual Google I/O developer conference, which wrapped up this week in San Francisco, packed its usual punch with a number of announcements and free stuff for attendees.
We saw the first example of Android Wear software for wearable devices, coming initially in LG's G Watch and Samsung's Gear Live, and later in Motorola's Moto 360. We saw Android TV, which Google will make available to new television sets from vendors like Sony and Sharp.
There was no mention of Google+ in the keynote; make of that what you -- and everybody else -- surely will. There wasn't much talk about Google Glass, either. No skydiver. And no Larry Page on the keynote stage.
In his mobile-focused keynote, Sundar Pichai, Google's SVP of Android, Chrome, and Apps, announced Android One, a new initiative that provides low-end hardware and software to emerging mobile markets, such as his home country of India. And he unveiled the new Android for Work initiative, which will partition personal and work apps on Android and Chrome for added security. (Look for Android at Work in the upcoming Android L operating system update.) And the new Android Auto.
Pichai also dropped some mad stats: a billion "30-day active" users (currently active) of the Android Platform, who send 20 billion test messages and take 93 million selfies per day. Android tablets now account for 62 percent of the global market, and app installs on the tablet is up 236 percent. He also mentioned that this year's conference is made up of 20 percent women, up from just 8 percent last year. Not sure what that means, either, but that's quite a year-to-year jump.
But the big news for developers at this year's show: 5,000 new APIs that will connect Android devices to a broad set of services on the Net and on other devices. Google also released the Android SDK for devs building apps for wearable computing.
IDC analyst Al Hilwa called the Google announcements "an amazing buffet of capabilities and APIs for developers that truly expands the Google ecosystem."
"The reach of the platform to wear, auto, home and TV, as well as connecting them together, really begins to show the connectedness of Android as the leading mobile platform," Hilwa told me. "What came across [in the keynotes] is the expansiveness of the platform overall. I did get a sense at the keynote that Google is talking to the whole world not just to a premium club. Does this mark a transition of the mobile leadership from Apple to Google? We will find out for sure when Apple makes its late fall announcements."
Google highlighted four new Cloud Platform tools for developers:
- A new version of Cloud Save, a service that enables non-relational, per-user data to be storage and synced in apps with no backend programming required.
- Google Cloud Monitoring, which uses technology from the company's recent Stackdriver acquisition to provide dashboards and alerting capabilities for finding and fixing performance problems.
- Cloud Debugger Monitoring, which changes the standard debugging model by allowing developers of cloud-based apps to set "watchpoints" on lines of code, which gives them "a snapshot of all the local variables, parameters, instance variables and a full stack trace," Google says.
- Cloud Trace Monitoring, a performance tool designed to give developers the ability to "visualize and understand the time spent by your application for request processing," and thus pinpoint bottlenecks.
"For developers there's a lot to play with here," Hilwa added. "APIs at every level will enable a new generation of apps connecting smartphones to other objects in life .... It will take some time for developers to absorb all the new APIs, but we will begin to see the impact of these announcements in the coming year. I expect that new SDK's will be added over time to cover other realms of the IoT world."
Posted by John K. Waters on 06/27/2014 at 2:19 PM0 comments
The Eclipse Foundation's annual Release Train will be in the spotlight later this week, but first a bit of that metaphorical illumination should fall on a new Foundation project. Announced on Monday, the newly organized Eclipse Science Working Group (SWG) is being described as "a global collaboration for scientific software." It aims to bring together groups from academia, industry and government to create open software that can be used in basic scientific research.
Actually, a better word here is "reused." As the Foundation's executive director Mike Milinkovich explained, the SWG is about freeing scientific researchers from the need to build so much software from scratch.
"There's a lack of reusable software components for basic scientific research," Milinkovich told ADTmag. "And yet more and more science projects are deeply dependent on software. The current model seems to be, they get a grant and then immediately start developing single-purpose software from the ground up. The goal of this new group is to create a set of tools and frameworks -- complete building blocks, really -- to help accelerate scientific research."
The SWG's founding steering committee includes Oak Ridge National Laboratory in Oak Ridge, Tennessee; Diamond Light Source in Oxfordshire, UK; and IBM. The SWG website lists 14 total members as of this writing, including Clemson University, Uppsala Universitet, The Facility for Rare Isotope Beams, Marintek, Lablicate, Kichwa Coders, Tech Advantage, and IFP Energies Nouvells.
The working group was originally proposed German programmer Philip Wenig, who works at Lablicate. Wenig, who is the developer of OpenChrom, an open source software tool for the mass spectrometric analysis of chromatographic data, brought the results of an inventory he had done of Eclipse-based scientific research tools, Milinkovich explained.
"It showed just how many groups were reinventing the wheel," Milinkovich said. "He argued that we could do better if we worked together, and a number of people agreed with him."
The current members of the working group will be collaborating on a range of open source projects focused on big-brain science software, such as tools for plotting and visualizing 1D, 2D and 3D data, and managing data for structured and unstructured grids: modeling and simulation software for physical and social sciences, such as physics, chemistry, biology, sociology, and psychology, among others; standard descriptions and definitions for scientific data; and infrastructure software to support scientific computing (e.g.: job launching and monitoring, parallel debugging, and remote project management).
"These are the kind of things that scientists are working with everyday," Milinkovich said. "We think we've assembled a visionary set of organizations here that are focused on the value they can bring to scientific research by collaborating on the basic software building blocks to make this research more productive."
The two initial SWG open source projects are based on code contributions from Oak Ridge National Laboratory and Diamond Light Source. The first is the Eclipse Integrated Computational Environment (ICE), which is a platform for modeling and simulation projects in science and engineering. The aim of the project is to provides a standard set of tools that allow scientists to set up the input model, launch a simulation job, analyze the results, and manage the input and output data. The code is based on technology created at Oak Ridge National Laboratory to develop a computational environment for modeling and simulation of nuclear reactors.
The second is the Eclipse DawnSci project, which defines Java interfaces for data description, plotting and plot tools, and data slicing and file loading. The project aims to provide interoperability of algorithms between different scientific projects. It's based on a code contribution by Diamond Light Source.
Keep in mind that these aren't Eclipse people, but rather experts who are bringing their special expertise to the platform.
"This is not Eclipse tool vendors looking for a way to approach science," Milinkovich said. "These are visionary scientific organizations realizing that they can use Eclipse to solve a problem."
Posted by John K. Waters on 06/24/2014 at 10:58 AM0 comments
GitHub.com this week unveiled an update of the application it launched two years ago to support Windows developers who want to use the Linux-centric code-hosting platform and its namesake revision control system for their projects. The company is describing Windows for GitHub 2.0 as a major update, emphasizing a new streamlined interface designed to help users focus on their work.
"Essentially, we wanted to create a workspace that is as distraction-free as possible," Tobias Ahlin, a GitHub designer and developer, told ADTmag. "In October we did a UI overhaul, just cleaning things up. Then we took another critical look at the UI and really tried to strip it down and reduce the number of menus and options you need to navigate, to get everything you need on one screen, so that it's very easy to use and it's easier to get things done on GitHub. As we say, it puts what you're working on front and center."
For example: In this new UI, the sidebar groups repositories by where they originated, so that those repositories associated with GitHub Enterprise, the on-premises version of GitHub.com, are easy to distinguish from a developer's personal projects, and it's simple to switch between them, Ahlin said.
Along with the cleaned up UI, the application comes with a self-contained version of Git, the bash command-line shell, and the posh-git extension for PowerShell. And it uses the ClickOnce installer.
This update also gives Windows developers new access to features familiar to long-time GitHub users, Ahlin said, including the ability to pick an ignore file template for a project when a repository is created, and option to include emoji and gifs in commit messages.
"We tried to look at what Microsoft has been doing with Metro for tablets and mobile, keeping in mind what's happening with iOS and Android, and then try to take that back to the desktop environment for Windows," Ahlin said. "Because, sadly, Microsoft has kind of neglected the design language around that. So we tried to bring all the best bits back to the desktop environment and create and experience that's feels very fresh.
GitHub, has become one of the world's most popular social coding sites. As I've pointed out before in this space, developers love the Git distributed version-control system developed by Linus Torvalds, and GitHub has played no small role in the growth of that popularity. The service has also enjoyed endorsements from the likes of the Eclipse Foundation, which has begun to allow the hosting of its projects on GitHub to attract new and maturing projects.
GitHub for Mac was released last year.
Posted by John K. Waters on 06/13/2014 at 9:20 AM0 comments
The amount of both mainstream and tech press generated by Apple's annual World Wide Developer Conference, winding down in San Francisco today, always catches me by surprise. It shouldn't, I suppose, but everyone covers this show. I agree with the argument that Apple has earned the attention with its bleeding-edge, category-creating, market-overhauling innovations over the past couple of decades, but it's still true that somewhere around 90 percent of all PCs worldwide are running Windows. Maybe I should look at the coverage of the WWDC as further evidence of the receding relevance of the PC as a personal computing platform.
Among the many announcements at this year's show (covered thoroughly by my colleague David Ramel here), Apple CEO Tim Cook called out the new software development kit (SDK) as "the biggest release since the launch of the App Store." The new SDK comes with more than 4,000 new APIs, and a feature called "Extensibility," through which devs will be able to extend services to other applications via the App Store.
But for my money, the official introduction of the successor to Apple's Objective-C programming language was the biggest news for developers this year. Dubbed "Swift," the new language sheds the "baggage of Objective-C" to provide "an innovative new way of coding for Cocoa and Cocoa Touch," as the Web site puts it. Where Objective-C relied on defined pointers, the Swift compiler infers the variable type. But it keeps such features as well-defined namespaces, generics, and operator overloading.
Apple says the new language will be able to co-exist alongside existing Objective-C files in the same project. Swift is ready for developers now who want to kick the tires, and it will be supported with the next version of the Xcode IDE (now in beta). When OS X Yosemite and iOS 8 are released later this year, developers will be able to submit Swift-based applications to the App Store.
I'm calling this the official introduction because Swift has reportedly been in development for four years. Chris Lattner, director of Apple's Developer Tools Department, says on his personal blog that he implemented the basic language structure in 2010 off the radar. Contributions from others started coming "in earnest" in late 2011, he writes, and the language finally became a "major focus" for his tools group last year.
"The Swift language is the product of tireless effort from a team of language experts, documentation gurus, compiler optimization ninjas, and an incredibly important internal dogfooding group who provided feedback to help refine and battle-test ideas," Lattner writes. "Of course, it also greatly benefited from the experiences hard-won by many other languages in the field, drawing ideas from Objective-C, Rust, Haskell, Ruby, Python, C#, CLU, and far too many others to list."
Of course, Swift isn't the only new (ish) addition to the programming language landscape. Under the category of emerging languages, there's Google's open-source Go and Dart; Red Hat's Ceylon; Opa; and Typesafe's open source Scala.
In fact, IDC analyst Al Hilwa believes we're living in "a golden age of programming languages."
"Computer scientists never tire of creating new languages, and this is illustrated by Apple's latest creation called Swift," Hilwa told me in an email. "There have not been too many examples of single-vendor-promoted languages achieving wide adoption. Most of the popular programming languages that have come to wide-spread use, like COBOL, FORTRAN, C, and Java, have had multi-vendor support. Objective-C was catapulted into fame by the unique disruption of Apple's iPhone, and C# was promoted by Microsoft during its pinnacle of dominance as the language for Windows apps."
Initial reactions to the language seem to suggest a promising future for Swift. As one breathless coder told me, "It's Objective-C with all the bad stuff scraped out." But Hilwa argues that the success of the language will depend largely on how hard Apple promotes it, and how well that promotion is received by the Apple appdev ecosystem.
Posted by John K. Waters on 06/06/2014 at 12:32 PM0 comments
Would you be surprised to learn that 82.5 percent of Java developers responding to a recently conducted survey said they favor the JUnit testing framework? Or that 70 percent reported an affinity for the Jenkins CI Server? Or that 69 percent prefer Git for version control? Or that 48 percent of developers reported using the Eclipse IDE? Yeah, me neither. But those were just a few of the stats -- both expected and surprising -- assembled from the latest survey of in-the-trenches Java developers by RebelLabs, the research and content arm of Java toolmaker Zeroturnaround.
This is the fifth year the Estonia-based company, probably best known as the maker of the JRebel JVM plug-in, has delved into the state of the Java developer tools-and-tech landscape with a global survey.
The results published in the 35-plus-page report, which came out last week, were gleaned from the 2,164 software developers responding to questions about what they like, what they do, and what they're interested in. "This survey rocked," said RebelLabs head honcho Oliver White in the report's intro (and his blog). White and his crew got a "better-than-ever responses" this year, he said, and the respondents even donated to charity.
Most of what you'll find in these survey results won't blow you away, but I, for one, like to see the numbers when someone thoughtful goes to the trouble of assembling them. It's a snapshot, to be sure, but it's a crisp one.
Among the survey's more intriguing numbers: Scala was among the JVM languages generating the most interest among Java developers. In fact, 47 percent said they'd like to learn it. Gradle topped the wish list of build tools the respondents would like to learn (58 percent), though only 11 percent reported actually using it. (64 percent said they currently use Maven). And more than a third of respondents said that "getting familiar with" Java 8 was one of their highest priorities in 2015. Also, a huge majority of respondents (71 percent) reported working on Web applications, with 15 percent working on libraries or frameworks, 11 percent working on desktop apps, and on 3 percent working on mobile apps. That last number surprised me, but White explained it in the report this way: "Presumably, the majority of mobile app developers are selecting not Java ME (SE embedded), but rather Dalvik (Android) or iOS."
The cumulative answers to the survey question about which version of Java respondents are using now was edifying: Most reported using Java SE 7 (65 percent), but one in four said they are still using Java SE 6. Adoption of the newly released Java SE 8 came in at 7 percent, but the report authors saw that as surprisingly, given that only a few application servers currently support it.
Most respondents reported using Java EE (68 percent), which confirmed the authors' expectations that the surveyed group was representative of the enterprise Java development segment. Most reported using Java EE 6 (49 percent), and about a third reported using Java EE 7. And here's a surprise: 1 in 6 developers responding to this survey reported that they are still using Java EE 5.
There's lots more in this report, including some fun fact about job titles, more on JVM languages, IDE preferences, and App Server stats. The report also quotes a number of Java jocks and luminaries. My favorite is from German technology consultant Markus Eisele, who, according to his blog bio, works daily with customers and projects dealing with Enterprise level Java and infrastructures:
"Java has been called 'dead' for years. But it's vital and new language versions get adopted with the industry-typical restrained uptake. For both Java SE and Java EE, nearly 2/3 of participants [in the survey] are on the latest two releases. The faster uptake on the EE side clearly expresses how important developer productivity and ease of use are today."
The 2014 RebelLabs 5th Java Tools and Technologies Report is available for download from the RebelLabs Web site. It's worth noting, too, that RebelLabs maintains a collection of over 25 technical publications, also available online.
Posted by John K. Waters on 05/28/2014 at 10:06 AM0 comments
A federal appeals court sided with Oracle on Friday, ruling that the 37 Java APIs at the center of the now four-year-old Oracle v. Google patent infringement lawsuit are, in fact, protected under U.S. copyright law. The appeals court overturned the 2012 ruling of Judge William Alsup of the U.S. District Court of Northern California, and referred the case back to that court, which will now take up the question of whether Google's use of those APIs in Android constitutes fair use.
To be clear, what the appeals court found was that the declaration code in Oracle's API packages, which Google copied verbatim, was copyrightable. (Google developed the implementation code independently, so it wasn't at issue.) As John T. Kennedy, an attorney at Dorsey & Whitney specializing in patent litigation, prosecution, and licensing, explained in an e-mail, the court found that the Oracle code had not merged with the functions performed by the code; that combinations of short code phrases, such as those used in the APIs, can be copyrightable; and the fact that the code serves a function does not preclude its copyrightability if, the as the court put it, "the author had multiple ways to express the underlying idea" at the time of creation of the code.
"Whether an alleged copier has multiple ways to perform a function was also found to be not relevant to the copyrightability of such code," Kennedy said, "but, might arise as a fair use defense. In a nutshell, since the functions performed by the Oracle APIs at the time of their creation could have been achieved by code 'written and organized in any number of ways' Oracle's code is copyrightable."
This case still has a long way to go, and Google has a chance to win a fair use argument, but the court's decision that APIs are copyrightable could have far-reaching implications for developers if it stands.
The court's decision could have a "chilling effect on the Java community and its developers," Redmonk analyst Stephen O'Grady predicts. "Android has been a boon to the [Java] language," he told ADTmag, "bringing it relevance in the exploding mobile development ecosystem. Any binding decision, therefore, that might impact its viability over the longer term raises questions for developers currently focused on building mobile Java applications for Android."
That chill could spread throughout the industry, said Gartner analyst Mark Driver, icing the long-standing tolerance for clean-room implementations. "Imagine if this precedent were on the books when they first started calling the NetBIOS API," he said. "That's a standard API for developing client-server apps. We would have a very, verydifferent personal computing industry, one that is much more fragmented and nowhere near the critical mass we have today."
The court's decision could have a great impact on Java, specifically, he said, because it would mark it as clearly not open. "Anyone with a strategy around open source is going to seek a path of technology that is far removed from anything closed, and vice versa."
Wayne Citrin, CTO of JNBridge, sees copyrightable APIs as bad for Java, which is also bad for Oracle. "Java is valuable to Oracle to the extent that it's relevant," he said. "Cutting off Google's Android/Java initiative at the knees certainly will make Java less relevant. Whatever money they make from the copyright on the APIs is outweighed by the long-term hit that they take on Java's relevance and reach."
Driver agrees: "If this decision stands, it's going to be a Pyrrhic victory for Oracle, because they're part of the industry. Ultimately, it hurts them too."
"At some point someone is going to have to sit down with the court and explain exactly how far reaching this is going to be," Driver added, "precisely how destructive it's going to be to the idea of open development and the concepts of the Internet, all the things that are driving most of the innovation that's happening today. Perhaps they'll take a step back and see that this isn't just an argument between two vendors."
But Citrin doesn't see any long-term negative affect on Java developers, especially those doing mainstream development. "Just about all 'mainstream' Java development (mostly server-side development written to run inside Java EE app servers) runs on Oracle JREs or other licensed JREs," he said, "so this should have absolutely no impact."
"As to how it affects Android developers, or developers using unofficial open-source JREs, I would gather that it would provide difficulties," he said, "though probably more so for Android developers, since Oracle has a specific target in Google. For open-source JRE projects, it's not clear who Oracle would go after."
Posted by John K. Waters on 05/12/2014 at 2:54 PM0 comments
I suspect that we'll remember Heartbleed as one of the few security vulnerabilities to have its own logo and URL. But we should remember it for the wake-up call it sounded for users of open-source software (OSS).
Heartbleed, as everyone who hasn't been camping in the wilderness for the past month knows, is a serious vulnerability in the OpenSSL cryptographic software library. OpenSSL is popular and widely used, so the vulnerability, which the Web site states, "allows anyone on the Internet to read the memory of the systems protected by the vulnerable versions," was a big news even outside tech media. We're talking hundreds of thousands of Web servers and products potentially affected. Security analyst Bruce Schneier characterized the seriousness of Heartbleed on his blog this way: "On a scale of one to 10, this is an 11."
The bug was reported to the OpenSSL team by security engineers at Codenomicon, a company that builds software for pre-deployment testing of business-critical products, and Neel Mehta, a researcher on the Google Security team. But it had apparently in the code since 2011. According to the Sydney Morning Herald, the bug was introduced by a German software developer and OpenSSL code contributor, who missed a bounds check in the handling of the TLS heartbeat extension that could be used to reveal up to 64k of memory to a connected client or server. (Thus the name, "Heartbleed.")
Once they knew about the vulnerability, the OpenSSL guys fixed it, fast-surprisingly fast, given the relatively small size of this particular open source community, which, according to Steve Marquess, president of the OpenSSL Software Foundation, lacks "the manpower levels needed to support such a complex and critical software product."
Writing on his blog, Marquess pointed to funding as a big part of the problem. His organization has been supporting this critical piece of software with about $2,000 a year in "outright donations," as well as some commercial support contracts and "work-for-hire" consulting. In the five years since the foundation was created, it has never taken in more than $1 million in gross annual revenues, he said.
In the week following the Heartbleed disclosures, the foundation received about 200 donations, Marquess said, "along with many messages of support and encouragement." Most of those donations were for between $5 and $10, and they amounted to about $9,000. (You can still donate.)
"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," Marquess wrote. "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 and governments who use OpenSSL extensively and take it for granted."
So the arrival of a badass bug that seemed initially to repudiate the OSS mantra "given enough eyeballs, all bugs are shallow," actually reinforced that notion, while raising some serious questions about the true responsibility of OSS users. I like the way Bruno Borges, principal product manager for Oracle Fusion Middleware in Latin America, put it on his blog. Although, he acknowledges, the developer and QA have responsibilities here, it is "The whole IT industry (companies and developers of all kind; FOSS or not) who uses OpenSSL for free but does not pay anything for it, and although being Open Source, don't look at it, don't review commits. Just expect it to work without bugs. These are the most to be blamed. (including myself)"
Jonas Falck, CEO and co-founder of Halon Security, weighed in on the subject in an e-mail: "The Open Source community has received a bad rap for the OpenSSL exposure," he wrote, "but the community has rallied together to patch the issue quickly. If anything, the Heartbleed issue has shown how reliant the Internet as a whole is on Open Source, so if corporations can give back to the Open Source community after taking advantage of OpenSSL for so long, there will be more eyeballs spotting vulnerabilities earlier in the future."
Crowdsourcing platform Bugcrowd has initiated a clever, if short-term solution to the Heartbleed problem with a Crowdtilt crowdfunding campaign to secure OpenSSL.
As cool as that campaign is (very cool), it's doesn't address the underlying problem. I thought Walker White, CTO of BDNA, which makes the Technopedia categorized repository of information on enterprise software and hardware, summed up the situation nicely during a recent conversation. (His company uses the repository to put all the hardware and software assets within an organization into a common, easily taxonomy.)
"It's the money-for-nothing syndrome," Walker said, "and it's not just OpenSSL. You have all these great products-Tomcat, Maven, Gradle, Jenkins, Git, all these development tools and frameworks. It is truly incredible what the open-source community has done. But vendors can't treat open source as something they can just plug in. We have to take responsibility for it-especially vendors who are embedding it into commercial solutions-and not just punt to the community when something goes wrong."
Shortly after I filed this story, news broke that the Linux Foundation is launching a three-year, multi-million-dollar project to fund open source projects that are "in the critical path for core computing and Internet functions-including OpenSSL. The funds for the project, called The Core Infrastructure Initiative, will be administered by the Linux Foundation and a steering group made up of backers of the project and "key open source developers and other industry stakeholders." Support will come in the form of funding for fellowships for key developers to work full-time on open source projects, security audits, computing and test infrastructure, travel, face-to-face meeting coordination, and other support, the foundation said.
"We are expanding the work we already do for the Linux kernel to other projects that may need support," said Jim Zemlin, executive director of The Linux Foundation, in a statement. "Our global economy is built on top of many open source projects. Just as The Linux Foundation has funded Linus Torvalds to be able to focus 100 percent on Linux development, we will now be able to support additional developers and maintainers to work full-time supporting other essential open source projects. We are thankful for these industry leaders' commitment to ensuring the continued growth and reliability of critical open source projects such as OpenSSL."
Along with the Linux Foundation, the list of "founding backers" of this effort includes Amazon Web Services, Cisco, Dell, Facebook, Fujitsu, Google, IBM, Intel, Microsoft, NetApp, Rackspace and VMware.
Posted by John K. Waters on 04/28/2014 at 5:02 PM0 comments
Back in January I talked with Eric Knipp, who manages Gartner's Application Platform Strategies research team, about some of the opportunities and challenges he saw on the horizon for application developers. During that conversation, he mentioned an intriguing idea that he was exploring: That crowdsourcing could be much more useful to enterprise app dev organizations than most people currently recognize.
That exploration is complete and Knipp's conclusions and recommendations are laid out in a new Gartner white paper, aptly entitled "Use Crowdsourcing as a Force Multiplier in Application Development."
Gartner defines crowdsourcing as "the processes of sourcing a task or challenge to a broad, distributed set of contributors using the Web and social collaboration techniques." Think Netflix Prize or XPrize, or on smaller-scope piecework, Amazon or Mechanical Turk. As Knipp puts it, it is a call for a custom application solution from an external developer community, the members of which expect to earn financial or reputational awards.
The competitive aspect is somewhat similar to open source, which Knipp calls "an important ancestor" to crowdsourcing, and communities do develop around crowdsourcing environments, but the dynamic is dramatically different. Where open source attracts committers, crowdsourcing attracts competitors.
"Most of the time, when you're working on open source, it's something that you want to use personally," Knipp told me. "I'm contributing to Docker, say, because I use it and I found a bug that I want fixed, or there's a feature I want to add to make it better for me and everyone else who uses it. But on the crowdsourcing side, for the most part, this thing that you're building is for a specific purpose and the ownership of the code goes to the sponsor. You're trying to win that contest, get that prize, get invited into private contests, and maybe even get a job. These are two very different sets of motivations, even though both have a community aspect."
Applying crowdsourcing to enterprise application development is about harnessing parts of the open-source model -- the competitive spirit, the application of multiple solutions to a problem -- and folding them into a business model that helps the enterprise do meaningful work, Knipp explained.
It also opens up a new leadership role for application architects as coordinators of "the activities of cutting-edge developers in a free market for technical talent," Knipp said. This model allows app architects "to apply the cloud operating model (scalable and elastic, shared, service-based, metered and delivered using Internet technologies) to the development and delivery of custom software."
Why turn to external sources for internal innovation? Because of the pressure on app dev organizations to leverage a broader set of experience and domain expertise than they have in-house to compete in a world sent into warp-speed competition by cloud, mobile and social trends.
Small or midsize businesses (SMBs) and startups have found successes with mobile and modern Web applications through crowdsourcing, Knipp said. But he insists that larger enterprises can also take advantage of this model. One secret of the SMBs success: applying crowdsourcing to greenfield application development, rather than extending or modernizing existing systems. Also, they tend to focus on the design, coding, and testing disciplines in the software development life cycle (SDLC).
Once the decision to crowdsource is made, Knipp said, the next most important choice facing an organization is which platform to use. The crowdsourcing process is mediated by platforms that connect the sponsoring companies with the competitors, and picking the right one is critical. Currently, most of the platform providers specialize in one phase of the SDLC. DesignCrowd, crowdSpring, and 99designs, for example, focus on the design phase, while uTest, Passbrains, and BugFinders focus on validating code and cross-platform functionality. Only one provider, TopCoder, offers a soup-to-nuts crowdsourcing platform. Knipp expects that situation to change as more enterprises recognize the value of crowdsourcing.
Knipp has a lot more to say on this subject in this must-read white paper. Highly recommended.
Posted by John K. Waters on 04/17/2014 at 4:56 PM0 comments