The Hyperledger project has come a long way in making the innovative blockchain technology used in Bitcoin a viable option for secure business transactions; hear more from Christopher Ferris in this keynote at the Open Source Leadership Summit.
The Hyperledger project has come a long way in making the innovative blockchain technology used in Bitcoin a viable option for secure business transactions; hear more from Christopher Ferris in this keynote at the Open Source Leadership Summit.
The one-year-old Hyperledger Project has already come a long way in making the innovative blockchain technology used in Bitcoin a viable option for secure business transactions. That was the clear message from Christopher Ferris in his keynote at the Open Source Leadership Summit in February.
Ferris, the CTO of open technology at IBM and member of Hyperledger’s leadership, said Hyperledger and blockchain technology could be enormously successful in private enterprise securing and verifying rapid, high value, and highly private transactions. Additionally, the collaborative open source foundation is nearing release of its production-ready distributed ledger code base, Fabric.
“We have the ability to think about how we might instrument all these different types of [private transactions] and essentially in antagonistic type environment and yet know that the information could be trusted,” Ferris said, “and that everybody actually shares the same copy of information.”
There are a few hurdles to clear first, Ferris said, and the project is still very young. The biggest issue is probably perception; Ferris said Bitcoin was built by anarchists looking to disrupt the banking industry and has had some notorious heists and scandals in its short history. That makes enterprise CEOs and CTOs a touch skittish.
Ferris said that’s why good governance and a truly open and collaborative environment are crucial for blockchain tech, and that’s precisely what Hyperledger is looking to provide. The organization currently has five top-level projects under its umbrella. They are:
Sawtooth Lake – A distributed ledger technology written in Python, supporting both permissioned and permissionless deployments.
Iroha – A simple, decentralized ledger design for mobile clients.
Fabric – A foundation for blockchain applications with a modular architecture that allows components, such as consensus, messaging, identity, and encryption services to be plug-and-play.
Cello – Orchestration for delivering blockchain as a service.
Blockchain Explorer- A user interface for exploring the state of the ledger.
Fabric is the project closest to a general release; each of these projects is led by a different team and is working to ensure interoperability with the other projects.
“Our goal is obviously to develop and create open source solutions for these technologies,” Ferris said, “and to provide that neutral open governance model to sustain these things. To develop a diverse ecosystem of communities. To educate the public and government and so forth on what this technology is, how it can be applied. To educate ourselves by bringing people together to help us explore different ways that the technology might be used in various industries. Then, again, to promote this notion of a community of communities.”
Another issue the technology has is generally slow throughput; Bitcoin can handle only about seven transactions per second, Ferris said.
“Anybody who’s been working on any kind of enterprise systems know that ain’t going to cut it for just about anything,” he said. “If you wanted to apply that technology to your ERP system for instance to track all the shipments and invoices and whatnot that go on in your enterprise, it’s not going to do it.”
Ferris said Hyperledger, which was started in February 2016, has grown from 30 general members to more than 110 in just a year. Two more premier members have joined in that time — Airbus and American Express — and Ferris said there are others in the pipeline. The project is growing rapidly and has a significant amount of momentum because it’s a very useful technology that’s almost perfect for open source, he said.
“This is a technology that is essentially perfect for open source,” Ferris said. “It’s potentially very revolutionary. We don’t want to have any one player in the ecosystem that controls all of it. We don’t want it to be monetized only by in IBM or somebody like that. We want it to be used universally by multiple parties.
“It requires special skills and it requires a diverse set of special skills. You have to have deep cryptographic capabilities, deep understanding of distributed computing, containerization, databases, database query engines and so forth. There’s a whole lot of different disciplines that are required to build this technology effectively and it needed a strong governance model.”
Watch the entire presentation below to learn more:
Learn how successful companies gain a business advantage with open source software in our online, self-paced Fundamentals of Professional Open Source Management course. Download a free sample chapter now!
Companies that use Open Source Software (OSS) find that it offers the most flexibility of any third-party software alternative. You are, for example, never locked into a vendor, their costs, their buying structures, or their re-distribution terms. Open Source enables vendor independence.
In addition, using OSS speeds development, lowers costs, and keeps companies on the cutting edge of technology by facilitating innovation. Open source communities provide a low-cost medium for incubation and testing of new capabilities. While open source ecosystems direct ownership and accountability back to the development teams.
All of this adds up to a competitive advantage for organizations that use OSS.
Previously in this series, we’ve discussed why OSS is faster and more cost effective. This time we’ll cover why open source software is also more flexible and supports innovation.
Open Source offers the most flexibility of any third-party software alternative. Here’s why:
● Vendor independence — as mentioned above, you are never locked into a vendor.
● No contractual limits on deployment — OSS often has very liberal terms attached to it for deployment, so you have the greatest possible flexibility on platforms, numbers of users, number of processors, or any other scaling factor that could impact the price of proprietary software.
● Source code allows customization — Because you’re in possession the source code, you may also customize OSS to meet your needs. And if your customizations are of value to others, the community may support your modifications in future releases.
● Open source communities encourage and facilitate customization — making it easier to extend the solution for particular use cases or to integrate with other products.
● Ongoing collaborative community support and maintenance – healthy Open Source communities provide ongoing support and encourage input and suggestions for improvements.
OSS was originally conceived as a way to facilitate development and innovation through collaboration. The open source approach has proven so effective for innovation, that many leading edge software technologies are driven by open source communities. For example:
● The Internet has been developed primarily as a large collection of individual, but related, open source projects.
● Software development tool innovation and integration is largely an open source domain.
● The incredible rate of innovation in the mobile communications space is only possible through OSS. Although Android is the primary example, even proprietary platforms like Apple’s iOS are largely built from open source components, like BSD Unix.
● Like the rest of the Internet, social media software has emerged from and grown through open source.
● The arena of scientific computing and massively parallel computing are almost exclusively open source domains.
Many open source communities exhibit rapid evolution that can be harnessed through participation to speed your company’s or your organization’s innovative processes. The open source ethos of bottom-up meritocracy directs ownership and accountability back to development teams. One of the best ways to introduce a new software idea, test new capabilities, and grow an active user base is through an open source community.
And finally, the innovation that open source enables is not just in the technical arena. The lack of contractual constraints in open source licensing allows for creative new uses, new distribution schemes, flexible and creative packaging and pricing approaches, and other forms of business and market innovation.
In today’s rapidly evolving markets, companies that consistently innovate, most quickly, at the least cost, will win. NOT USING open source software may place your organization at a disadvantage.
However, there are some operational challenges that companies must face when they embrace the open source development revolution. We’ll cover some of these challenges next week and then finish up the series with an overview of some of the legal risks involved with poorly managed OSS.
Read more:
Using Open Source Software to Speed Development and Gain Business Advantage
One of a company’s first challenges when starting an open source compliance program is to find exactly which open source software is already in use and under which licenses it is available.
This initial auditing process is often described as establishing a clean compliance baseline for your product or software portfolio. This is an intensive activity over a period of time that can extend for months, depending on how soon you started the compliance activities in parallel to the development activities.
Below are some recommendations, based on The Linux Foundation’s e-book Open Source Compliance in the Enterprise, for some of the best ways to achieve initial license compliance.
Organizations achieve initial compliance through the following activities:
• Early submission and review of open source usage requests.
• Continuous automated source code inspection based on a predefined interval of time for all source code.
• Continual source code scans, including code received from third-party software providers, to intercept source code that was checked into the code base without a corresponding compliance ticket. Such source code scans can be scheduled to run on a monthly basis, for instance.
• Enforced design and architectural review, in addition to code inspections, to analyze the interactions between open source, proprietary code, and third party software components. Such reviews are mandatory only when a given interaction may invoke license compliance obligations.
If a company fails to establish baseline compliance, it is almost guaranteed that future revisions of the same product (or other products built using the initial baseline) will suffer from compliance issues. To guard against such scenarios, companies should consider establishing other elements of a complete open source management program, including the following:
• Offer simple but enforced policies and lightweight processes.
• Include compliance checkpoints as part of the software development process as it moves from concept into shipping
a product or software stack. Ideally, with every development milestone, you can incorporate a corresponding compliance milestone, ensuring that all software components used in the build have parallel and approved compliance tickets.
• Ensure availability of a dedicated compliance team.
• Utilize tools and automation to support efficient processing of compliance tickets.
There are several challenges in maintaining open source compliance, similar to those faced when establishing baseline compliance. In fact, many of the steps are identical, but on a smaller, incremental scale. We’ll cover recommendations for maintaining compliance in the next article in this series.
Read the other articles in this series:
The 7 Elements of an Open Source Management Program: Strategy and Process
The 7 Elements of an Open Source Management Program: Teams and Tools
How and Why to do Open Source Compliance Training at Your Company
Basic Rules to Streamline Open Source Compliance For Software Development
How to Raise Awareness of Your Company’s Open Source License Compliance
SDxCentral is sponsoring a raffle for tickets to Open Networking Summit — the industry’s premier open networking and orchestration event, which highlights open source initiatives and innovation.
In this registration raffle, four winners will receive a complimentary pass to attend Open Networking Summit 2017, April 3-6 in Santa Clara, California.
Enter now for your chance to attend the conference and hear from networking visionaries, including:
Martin Casado – Andreessen Horowitz
Amin Vahdat – Google
Justin Dustzadeh – Visa
Sandra Rivera – Intel
And many more
The raffle ends on March 19 at 11:59pm Pacific Time.
Have you heard about dotCloud? If you haven’t, I’m going to give you a hint: it is a PAAS company. Another hint: eventually, dotCloud open-sourced their container engine. That container engine became Docker.
This is a quasi-archeological account of some of the early design decisions of dotCloud, some of which have shaped how Docker is today (and how it is not). “How is this relevant to my interests?” you ask. If you are not using containers, and not planning to, ever, then this article will not be very useful to you. Otherwise, I hope that you can learn a lot from our past successes and failures. At the very least, you will understand why Docker was built this way.
Read more at Taos
When Wim Coekaerts is solving problems and building things, he’s happy. When he’s not, he’s not.
In his long career, he’s found joy working on early database appliances, and later guiding Oracle’s effort to make Linux, the open source operating system he’d played with since his school days in Belgium, its OS of record. Now, “Linux has become the operating system of the cloud,” Coekearts says, so he sees lots more fun on the horizon.
Read more at Forbes
Do you love to code? Are you a trailblazer in secure app development, IoT or bot app development? Want to share your microservices or container success story? If so, DevNet Create wants you as a speaker at its first annual event May 23-24, 2017, in San Francisco.
DevNet Create is an event sponsored by Cisco that brings together a community of application developers, infrastructure and DevOps engineers, and IT pros who want to define and build modern applications on a programmable infrastructure.
Interested in speaking? Simply visit https://www.papercall.io/devnetcreate2017 by March 23, 2017 to submit your original topic or demo.
Below are some topic ideas to get you started—but don’t just stick to the list. They are looking for creative approaches, interesting ideas, and thoughtful what-ifs. So get to submitting and we’ll see you in San Francisco!
• How to Design and Build APIs
• Where Apps meet Infrastructure
• Where Infrastructure Meets Apps
• Software Defined Networking
• Cloud Native, Containers, and Microservices
• Bots, Chat, APIs and Enterprise Collaboration
• IoT & Edge Computing
• Security for Apps and Infrastructure
• Industry & Vertical Solutions
• Multimedia, AR/VR, Next Generation Interfaces
• Analytics & AI
• UX & Design
WebAssembly is a new type of code that can be run in modern web browsers — it is a low-level assembly-like language with a compact binary format that runs with near-native performance and provides languages such as C/C++ with a compilation target so that they can run on the web. It is also designed to run alongside JavaScript, allowing both to work together.
In a nutshell
WebAssembly has huge implications for the web platform — it will provide a way to run code written in multiple languages on the web at near native speed, with client apps running on the web that previously couldn’t have done so.
Read more at Mozilla Developer Network
You’ll find negative stereotypes for most jobs. “Ambulance-chasing lawyer.” “Greedy banker.” “Corrupt politician.” One that hits close to home for me? “Ivory tower architect.” You know the type. Focused on pristine diagrams and IT standards instead of real-life concerns. When I was an IT architect, I tried to buck that stereotype. But unfortunately, it’s a reality within many companies and slowing down their required evolution. That doesn’t have to be the case. How can enterprise architects champion the org changes needed to compete with the cloud-natives? Let’s talk about it.
Look at what we ask for from enterprise architects today. I pulled these from public job postings:
Read more at Pivotal