Category: products

  • Is Open Source More Risky?

    Is Open Source More Risky?

    There’s been a long-running debate over open source and security, and it goes something like this:

    Pro: Open source is awesome! Given enough eyes, all bugs are shallow. This is why open source software is inherently more secure.

    Con: Hackers can see the code! They’ll look at the source code and find ways to exploit it. This is why open source software is inherently more insecure.

    And on and on… ad nauseum. There are a variety of studies that each side can finger to help state their case. The problem as I see it, is that we’re not even talking about the same thing. If someone says open source software is more or less secure, what are they actually talking about? Do they mean software you download from the web and push into production? Or do they mean vendor-supported solutions? Unless we can agree on that, then any further discussion is pointless.

    Open Source Products

    So let’s shift the conversation to an apples vs. apples comparison so that we’re discussing the same things. According to a survey by Black Duck, upwards of 96% of commercial software solutions use open source software to some extent. This means virtually *all* new software solutions use open source software. So, when someone argues whether open source is more or less secure, the question to ask is, “more or less secure than *what*?” Because as we can see, the number of software solutions that *don’t* use open source software is rapidly dwindling.

    To save everyone’s breath, let’s change the dynamics of this conversation. Let’s compare “raw” upstream open source code vs. supported software solutions backed by a vendor. As I’ve mentioned before, you can do the former, but it helps if you’re Amazon, Google or Facebook and have an army of engineers and product managers to manage risk. Since most of us aren’t Amazon, Google or Facebook, we usually use a vendor. There are, of course, many grey areas in-between. If you choose to download “raw” code and deploy in production, there are naturally many best practices you should adopt to ensure reliability, including developing contingency plans for when it all goes pear-shaped. Most people choose some hybrid approach, where core, business-critical technologies come with vendor backing, and everything else is on a case-by-case basis.

    So, can we please stop talking about “open source vs. proprietary”? We should agree that this phrasing is inherently anachronistic. Instead, let’s talk about “managed” vs. “unmanaged” solutions and have a sane, productive discussion that can actually lead us forward.

  • Transform Your Business with Open Source Entrepreneurship

    Transform Your Business with Open Source Entrepreneurship

    This is a webinar I did for the Linux Foundation earlier this month. If you missed it, you can catch it on demand!

     

  • Kite Demonstrates Continuing Toxicity of Silicon Valley

    One of the most frustrating parts of being in open source circles is battling the conventional wisdom in the Valley that open source is just another way to do marketing. It’s complicated by the fact that being a strong open source participant can greatly aid marketing efforts, so it’s not as if marketing activities are completely unrelated to open source processes. But then something happens that so aptly demonstrates what we mean when we say that Silicon Valley has largely been a poisonous partner for open source efforts. Which brings me to this week’s brouhaha around a silly valley startup looking to “Make money fast!” by glomming onto the success of open source projects.

    To quote from the article:

    After being hired by Kite, @abe33 made an update to Minimap. The update was titled “Implement Kite promotion,” and it appeared to look at a user’s code and insert links to related pages on Kite’s website. Kite called this a useful feature. Programmers said it was not useful and was therefore just an ad for an unrelated service, something many programmers would consider a violation of the open-source spirit.

    It’s the “stealing underpants” business model all over again.

    1. Get users and “move the needle”
    2. ?
    3. Profit!

    Step 1 above is why we actually have valley poseurs who unironically refer to themselves as “growth hackers.” Only in the valley.

    The really sad part of this is that the methodology outlined above is terrible, not just because it’s unethical, but because it’s counterproductive to what Kite wants to accomplish. As I’ve mentioned countless times before, a project is not a product, and trying to turn it into one kills the project. The best way to make money on open source is to, big surprise, make a great product that incorporates it in a way that adds value to the customer. In this example, this means taking projects like minimap and autocomplete-python, producing commercial versions of them, and make them part of an existing product or offer them up as separate downloads – from the company site or part of a commercial distribution.

    The worst part of all this is there are still investors and business folks who think that doing is Kite did is the only way to make money from an open source project. It’s not. It’s a terrible maneuver from both an ethics as well as product development standpoint. It’s once again conflating open source with marketing, which is one of the reasons I started this site – it’s an unforced error and should be part of any “open source product 101” curriculum.

  • IoT Security: a Distributed Product Failure for the Ages

    IoT Security: a Distributed Product Failure for the Ages

    A Curious Case of Internet of Things

    Last year millions of IoT (Internet of Things) devices were compromised and turned into zombies to launch massive DDoS attacks that brought down a huge chunk of the Internet. Those were  not isolated cases; every week there is a new breach, a new security failure that poses a serious threat to our infrastructure, our economy and even our lives.

    These ‘insecure’ IoT devices are only going to grow in number. According to Gartner, by the end of 2017, there will be over 8.4 billion connected devices in the world. Take a moment and think about it. What kind of damage could 8.4 billion insecure IoT devices cause?

    I’ve spent the past two weeks talking to more than a dozen experts from the IoT world to get a better grip of the situation and understand how real these threats are, what are the causes, and what can be done to mitigate them, if it’s even possible to be mitigated.

    I would first like to thank the following industry experts who helped me with this story: Mark Shuttleworth, CEO of Canonical; Philip DesAutels, PhD, Senior Director of IoT at EdgeX Foundry; John Reno, Technology product marketing at Cisco; Nadir Izrael, CTO and co-founder, Armis; Marc Blackmer, Manager, Product Marketing, Industry Solutions Security Business Group, Cisco; Mark Thacker, Security Strategist at Red Hat; Eliav Gnessin, Founder and CTO of Cloud of Things; Noah Harlan, Founder of Two Bulls; Aaron Lint, VP of Research, Arxan; Ken Carroll (Vice President/Principal IoT Architect ) at Cloud Technology Partners; Robert Kusters, Director of Product Marketing, Inpixon; Bruce Schneier, an American cryptographer, computer security professional, privacy specialist and writer; Thibaut Rouffineau, Head of Marketing for Devices and IoT at Canonical; Thomas Pfeiffer, board of directors of KDE e.V….and many more.

    What is “Internet of Things”?

    Internet of Things or IoT is a marketing term for connected devices, just the way retina display is a marketing term for HiDPI display. The term was coined by Kevin Ashton of Procter & Gamble, in 1999. “Any edge device that connects to either a central system or makes itself available via the internet can plausibly be viewed as IoT,” said Noah Harlan, Founder of Two Bulls.

    IoT is a very broad category of diverse devices that can be categorized on the basis of usage. In general, there are three category of IoT devices:

    Industrial IoT: Devices that control infrastructure or robots that build other objects. These have been connected to the internet to report on status, be controlled remotely and keep a system-wide log.
    Consumer IoT: This includes devices like cameras, thermostats, bulbs, smart TVs and more. Every consumer device with an IP address is a Consumer IoT device.
    Enterprise IoT: These sit between the two previous categories and are similar to consumer devices, but with the same expectations and functionalities as Industrial IoT devices, such as performance, connectivity and security.

    Ken Carroll, Vice President and Principal IoT Architect at Cloud Technology Partners says these categories can be further broken down into different industries such as: Industrial & Manufacturing, Energy Logistics & Transportation, Retail, Building and City Systems, Healthcare, Agriculture Automotive, Oil & Gas, and Consumer.

    According to IDC estimates, Manufacturing saw the largest IoT investment over $178 billion, followed by Transportation ($78 billion), and Utilities ($69 billion). Consumer IoT purchases was the fourth largest market segment in 2016.

    If you are curious why we need these categorizations, just look at the largest market and compare with the most vulnerable one. That will help understand what makes IoT devices so insecure. Despite being the smallest of the four markets, Consumer IoT is the most vulnerable category. When you hear horror stories, they are almost always about consumer IoT, the smallest pie of the IoT market. “The devices primarily giving a bad name to the security characteristic of IoT devices are ones which are very cheaply mass manufactured. These tend to be targeted for mass sales into the consumer market, such as cameras,” said Carroll.

    A quick peek into the evolution of IoT devices and how Consumer IoT came into existence will help provide clarity.

    The Evolution of IoT

    IoT devices have evolved from big, expensive and complex machines. “Early on, companies like Burlington Northern Railroad realized that it was very expensive to keep railroad traction motors failing in the field. If you can monitor and predict when certain types of failure will happen then you can fix them even before they happen and save a lot of money,” said Philip DesAutels, PhD, Senior Director of IoT at EdgeX Foundry.

    In the early days it was a very expensive and complex feat with satellite communication and hardened computers to run inside of hot trains. Over time, new technologies emerged and companies like Wi-Tronix started offering solutions to the railroad company.

    As machine 2 machine (M2M) technologies became simpler, easier and cheaper, IoT moved on from traction motors to heavy equipment to trailer trucks to every car made in the world. It’s now in our cameras, door-bells and even light bulbs.

    That’s consumer IoT.

    As IoT trickled down, while the basic concept remained the same, it served different purposes

    While Industrial or enterprise use case was more about efficient business solutions, consumer IoT was all about products and features at attractive pricing.

    DesAutels provided the  example of a waste oil management solution. Traditionally a waste oil management company would roll out trucks once a week to check if the customer needs to pump out waste oil. It’s a very inefficient way as trucks would be driving around even if there were no oil to be pumped. With IoT solutions you can monitor remotely and if pumping is required,  you can optimize the delivery of vehicle in real time, reducing the number of trucks and the number of trips that the vendor make.

    In this example, IoT was not a product or feature. It helped a company cut costs and become more efficient. On the consumer side, you will find things like Ring doorbells that provide a sense of security. Google Nest offers the convenience of controlling the thermostat from the comfort one’s bed or even outside the home.

    Consumer IoT is no different than any other consumer product, however, the security implications of your personal laptop are totally different from the security of a corporate laptop. Your company provided laptop has better security to protect the confidential company business, it’s guided by very strict regulatory and compliance policies where as your personal laptop has none.  In industrial IoT,  security means the availability of overall system – keeping the factory running, maintaining the reliability and safety of the grid.

    “In the enterprise IoT, the investment in securities is being made to protect the confidentiality of business data and privacy of personally identifiable information,” said John Reno, Technology product marketing at Cisco.

    In the consumer IoT landscape, neither the vendor nor the user are concerned about the fact that someone may hack into their baby monitors or VTech toys to steal data or compromise the network.

    Why are Consumer IoT devices so insecure?

    Economy. Consumer IoT is is a very thin margin business where vendors try to cut costs in every possible way to meet a price point that’s attractive to customers. The business model that allows you to purchase, for example, a high quality IP video camera for <$100 does not support lifetime updates of software, it doesn’t allow built in security features.

    “Most consumer IoT vendors live off thin margins. As a result, market pressures can drive some manufacturers to strip out security functionality either to get to the market in time to be competitive, or to save on cost for commodity devices where margins are thin, said Marc Blackmer, Manager, Product Marketing, Industry Solutions Security Business Group, Cisco.

    A majority of IoT vendors are hardware manufacturers who monetize from selling more hardware devices. They follow the old-fashioned approach to distribution where they develop a product, sell it and move to the next iteration of the products with ‘new’ features, leaving behind a long trail of unmaintained products.

    “If economics are there people will create a system. There is no economic incentive for a light bulb manufacturer to produce something that is patchable. Even Microsoft doesn’t patch windows XP, as  there are no economical incentives.” said Bruce Schneier, an American cryptographer, computer security professional, privacy specialist and writer. “A technology solution doesn’t matter and I don’t care.”

    However, the economy itself is not to be fully blamed. Lack of legal liabilities, regulatory or compliance restrictions to build security into those products is also one of the major reasons behind unmaintained products. If you purchase a super expensive smart TV or Smart refrigerator from any of the leading manufacturers like Samsung or LG, you will not find any information on their guarantee of support page about the duration that these  $2000+ devices will receive software updates. A typical fridge has a 10-16 year life,  but these vendors may stop pushing updates after one or two years leaving them exposed to attacks for the rest of it’s existence.

    In April 2017, security researchers found 40 critical bugs in Tizen OS that runs on millions of devices. In this case we are not talking about$50 IP cameras made by an unknown Chinese ODM, we are talking about premium devices from the world’s second largest electronics company, after Apple.

    Not all vendors have malicious intentions to not keep things patched and leave their users vulnerable. Some of these IoT vendors are new to this field and don’t have experience creating IP-enabled devices.

    “I’m sure many people would have wondered why they’d need to secure a connected surveillance camera. After all, there’s no valuable data on a camera. Then Mirai botnet hit, proving the value is in how a compromised device can be used,” said Marc Blackmer, Manager, Product Marketing, Industry Solutions, Security Business Group, Cisco.

    They ignore the basic concepts of security. “It’s as if we’ve forgotten 20 years’ worth of accumulated security best practices like not using hard coded default passwords for root accounts,” said Nadir Izrael, CTO and co-founder, Armis.

    Robert Kusters, Director of Product Marketing, Inpixon said that security risks are created when IoT devices are designed to replace existing devices, offering more convenience and intelligence in order to manage remotely or save on costs.

    “These devices often follow the same operating model that they had when they were not connected and security was an afterthought,“said Kusters. “Once a device is connected to a company network or the internet, it becomes a node that any hacker can see, and potentially exploit, either to discover other connected devices, such as company servers or to use as a bot for use in attacks like a DDOS.”

    Irrespective of whether the above reason is applicable in the particular use-case, the bottom line is that IoT devices are insecure by design. Economy is certainly a primary factor, but it’s not the only factor. There are technological reasons too. One of the biggest challenges is that these devices are not updatable.

    “When devices are deployed which are connected but can’t be updated or rely on hard-to-update common default security credentials, you are asking for a problem,” said Noah Harlan, Founder of Two Bulls.

    You might be surprised to hear, but there is a genuine reason why many IoT vendors avoid software updates of their devices. “Software updates can easily cause problems – and the easiest way to avoid problems caused by software updates is to avoid software updates,” said Mark Thacker, security strategist at Red Hat.

    Let alone inexpensive IoT devices, software updates have bricked iPhones and iPads. As a result, IoT vendors embrace the ‘release and forget’ model where they never bother to update software on working devices, which leaves these connected devices vulnerable.

    That’s a technological problem.

    Is there any way that smooth software updates can be guaranteed? Since IoT vendors never planned to update these devices, many such devices lack an interface for users to update them. And if there is a hardware interface for updates, like a USB port, what if an organization has 10,000 of those devices? “The likelihood that they’ll get patched is slim to none,” said Blackmer.

    Those vendors who do want to be able to update their devices, still face the dilemma of updates breaking their devices.

    “Automatic updates are the way forward for the IoT. Users shouldn’t even have to think about those updates, and should be able to rest assured that any security updates have already been pushed to the device within moments of being certified,” said Thibaut Rouffineau Head of Marketing for Devices and IoT at Canonical.

    Canonical has created a lightweight operating system called Ubuntu Core, that’s designed for IoT devices and can provide IoT players with a secure OS that enables them to not only push out updates over the air, automatically, but to have an operating system that rolls back to a previous state if those updates don’t work as designed.

    There are some caveats. “There are environments, like industrial control networks and medical device networks, where automatic updates may introduce serious, if not dangerous, problems. Even if the odds are 1 in 1,000, the impact of, say, a bricked device can be catastrophic,” said Thacker.

    You don’t want to deploy automatic update mechanisms in those cases. In such cases the update mechanism should be in the hands of the operators to allow for testing ahead of deployment.

    Even in solutions like Ubuntu Core, there is a roadblock. “One big question is who should be responsible for updates – the IoT device vendor, the IoT infrastructure vendor, the IoT application vendor or systems integrator, or the customer?” asked Aaron Lint, VP of Research at Arxan.

    That’s just one of the many hurdles; the IoT landscape is very diverse. It’s a chipset and processor nightmare. “There are so many different board types and everyone is rolling their own, so it would be a very high cost to earn market share by adding support for new chips and catching up to existing ones,” opines Lint.

    In addition, not every device out there is capable of running Ubuntu Core or can support such auto update mechanism. Each solution is very specific to the device, its system resources, its purpose, and many other things.

    Whether a device runs Ubuntu or not, Blackmer believes that an ideal operating system would include at least some minimal security capabilities, if even just requiring authentication and forcing the user to change the default credentials. In addition, it must be upgradable.

    The new OS approach will make edge devices safer to a degree, but they’re just one part of an overall IoT solution. Most IoT devices run on Linux that already has all the needed capabilities; all that is needed is proper implementation. “Vulnerabilities arise mostly from poor operational practices rather from devices – the devices tend to be secure,” said Carroll.

    When we look at the whole problem, especially those related to devices, we realize it’s actually not an IoT problem. In fact, in most cases the security issues that we hear about are not IoT issues, but rather product life cycle issues and are applicable to any product. Even the high-profiled D-link camera vulnerability was a product problem.

    “If we take those cameras and those dishwashers 15-20 years ago, we knew how to solve both those security problems . As soon as we got a web server, we learned how to patch it. As soon as we got a remote machine we figured how to do firmware management,” said DesAutels.

    DesAutels opined that we should not blame these companies as they are making the same mistakes that their predecessors made in other domains. He stressed that these are not IoT problems, these are classic examples of product life cycle management.

    “You need to know SDLC (systems development life cycle), you need to know pen-testing. We know how to build secure products, we do it everyday in the enterprise world where people work across corporate networks securely. We do it in the mobile world. All we need to do is apply the same practices to the IoT world,” said DesAutels.

    At the same time it’s unfair to put all the blame on the edge devices alone, though they are big culprits. The entire IoT stack is comprised of three components: the edge device, the backend server and the IoT gateway that sits between the two and plays a critical role in security. Any of these three components can be compromised, as happened in the case of Miele dishwashers where the backend server was compromised that gave away access to connected devices.

    An architectural approach is what is needed to build security into the various layers and events involved in an IoT deployment. IoT devices should treat the network as simply a transport to connect to their specific server, not something to interact with. IoT devices should, by design, be restricted from talking to anything but their target server and preventing anyone else on the network from talking to the IoT device.

    IoT gateway can play a very critical role in mitigating attacks, especially in the enterprise use case. A hardened IoT gateway can act as a shield for enterprise servers, data assets, and business applications

    “Users can enforce security policies such as access controls, validate identities, manage certificates, perform encryption/decryption as needed, implement a VPN for connection to backend systems, etc.,” said Thacker. “Using gateways in this way is part of a multi-layer approach to IoT security that is a must when considering how to protect a distributed computing system, which all IoT implementations are.”

    Companies operating in the industrial/enterprise IoT space are already doing it. Cisco offers industrial switches and routers that form the basis of IoT networking infrastructure. These gateway devices connect robots, programmable logic controllers and a variety of sensors that have been in the factory before but were either not connected or connected through proprietary networks.

    These solutions allow companies to integrate security within the IoT infrastructure. As a result, not only the modern, but also the legacy infrastructure benefits from the rich capabilities of access control, encryption, authorization… all within the routers and switches. The IoT network becomes the censor and enforcer and allows companies to enforce security within the IoT network infrastructure, explained Reno.

    “If you don’t worry about all of it, end to end, then you’re not thinking about security seriously,” said Noah Harlan, Founder of Two Bulls.

    There is increasing collaboration between IoT companies that will further make these devices more secure. As the IoT market is maturing we will also see standardization around protocols and transports. It’s a well-established fact that open standard, open technologies are more secure as compared to closed, even if widely used technologies.

     

    Industry wide efforts to make IoT more secure

    A lot of efforts are already underway in that direction. MUD aka manufacturers usage description is an standard which is backed by Cisco. It’s emerging as a universally standard way of describing device capabilities that will form the foundation of being able to authenticate and authorize devices on the network.

    There are industry wide efforts like SDP (security defined perimeters), where the companies are working on implementing additional technologies in devices that might have inherent risks in them to limit their exposure surface.

    EdgeX Foundry is working on a project that will provide customers with a way to plug in security that can control components and exposure surface of components. Instead of mandating or guaranteeing security, they are enabling customers to use their own plugins and managers.

    “OMA has created some standards, such as DM and LWM2M, and there are a few others too. Some vendors try to establish standards, such as Intel with EPID. The Industrial Internet Consortium has been attempting to construct a standard. Perhaps the best bet are the vendors, like Intel or those in the device management domain (Device Authority, Movana…),” said Carroll.

    All of these technologies and measures fail if companies don’t want to use them. At the moment the main cause of lack of IoT security is lack of accountability and security best practices. OS or update mechanisms are not silver bullets that magically solve all problems, it’s ultimately up to the vendors, organizations and consumers to secure their own networks and devices.

    We are left with  the root cause as potentially financial in nature. The cost of creating securable devices in the first place is high, and when you throw security into the mix it becomes even more costly. We need to create some incentives for IoT vendors so that they can adopt the best practices and technologies that are applicable in their cases.

    IoT needs new business models

    At the same time we can’t expect a hardware manufacturer to transform into security experts. They excel at making good devices, let them do it. That creates a unique opportunity for new business model. I call it ‘Remotely Managed IoT’.

    We have already seen such a model in the cloud space where start-ups focus on writing exciting applications, without having to worry about their cloud infrastructure. It’s companies like Rackspace or Mirantis that offer managed cloud solutions.

    The same model can be replicated in the IoT world where vendors can offer services to manage and keep IoT devices safe and secure. There are companies like Redbend (now part of Harman) that offer complete management of IoT devices, including firmware update management. There is a member of the EdgeX Foundry, Cloud of Things that offer a unique connected device management solution for OEM product manufacturers and systems integrators (SIs) enabling them to connect any device to any cloud, making the device IoT-ready within minutes.

    Regulations are the last resort

    When no technology, best practice, business model or economic incentive can save IoT, it’s time to look up at regulations. IoT has already caused way too much damage to our economy and looking at the scope of IoT devices, we have no idea what kind of havoc it will cause. The only way to make them secure is by forcing through law. Regulations can in fact help the industry as inspires new business models.

    “Lack of regulation and standardization, as well as the lack of accountability for manufacturers means there is no financial or legal incentive to do this right.” said Izrael.

    “It’s very easy to create incentives in our society. They are called laws. That’s how we create incentives to pay your taxes to not murder your neighbor. For companies to not put sugar water in baby foods and not to make PJs catch on fire and that’s care of safe, air planes. Laws and regulations are how we do this and when economic incentives are not there that’s when laws step in that’s how society works. If you want to fix this, pass laws.,” said Schneier.

    But laws cost money. It makes things expensive. “It’s more expensive for you to buy a ticket on a plane that won’t crash. It’s more expensive to buy a car with safety features,” said Schneier. “These are expenses and we force companies to spend the money and pass the cost onto the consumer because as a society we think that’s a good idea. There is no other way.”

    Mark Shuttleworth, CEO of Canonical believes that customer awareness will also play a big role in improving situation with IoT. According to him, it will be a mix of three components. The first is customer awareness where people will be more educated about investing in IoT devices and purchase the ones that are healthy and safe, second would be the cost associated with failure when companies don’t take responsibilities, and the third is regulation.

    Commenting on ‘carrot and stick’ or economic incentives and regulatory restrictions, Shuttleworth said, “There are a lot of ways to use commercial leverage to fix that kind of problem but in the end you also want some structural regulation. I am sure different countries will take different approaches, but at the end of the day it’s a combination of market and regulation that will change things.

    A lot of work is already underway. Harlan has worked with members of Congress on their first steps looking at IoT, in particular Cory Booker who is co-sponsoring the DIGIT Act which is making its way through Congress. Harlan advised them to work to avoid a patchwork of security rules (one set for health, another for automotive, another for consumer, etc…) as that would lead to conflicting rules and stifle innovation. Regulators should stay out of the minutia of defining how to comply and simply state what compliance means. “This frees the industry to innovate and gives them a bar to measure against,” said Harlan.

    DesAutels believes that firmware management and necessity to manage firmware is going to be so critical to product sales that it’s just a matter of time that companies will have to get a firmware management certificate from some regulatory body in the US and in the Europe. He is a strong supporter of firmware management as a requirement in IoT devices.

    All of it sounds good, but there is one large, genuine problem that’s still remains unanswered. There are many cases where companies that built those IoT devices cease to exist. Regulation won’t help in such cases. There will be millions of insecure devices waiting to be turned into zombies. DesAutels advocates for building kill switches into devices so companies or government agencies can turn those devices off. It may sound like a good idea, but it can be abused. It’s also  injustice to customers who bought those devices.

    Instead of building kill switches, companies should be compelled to allow users to use their own firmware on these devices. Thomas Pfeiffer, board of directors of KDE e.V., said that open source communities can create custom firmware for devices and keep them secure and alive. However, in order for the community to write firmware, they need to be provided with drivers or at least be able and allowed to reverse-engineer them.

    “IoT vendors can be legally required to publish the specifications needed to write a driver and copyright and patent law could be modified so that reverse-engineering a driver would not be illegal.”  said Pfeiffer. “What we would like to see is a mindset within IoT manufacturers of the open-source community as friends who can keep their hardware useful even after it is not economically viable anymore for the manufacturer to support them, not as a threat they have to lock out,”

    Conclusion

    My takeaway from this discussion is that ‘IoT’ itself is not a security risk. It’s not LZ 129 Hindenburg that’s going to kill us all. Different use-cases, different industries create different incentives for IoT companies to adopt different approaches to the market. What consumer IoT needs is more incentives for companies to build security features into their devices.

    There are new business models like ‘managed IoT’ that can create a very lucrative market. In the end, whether it’s customer awareness, regulations or new business model a smarter approach to security is healthy, necessary even, for the growth of the IoT ecosystem. Regulations also mean news ways to monetize from it. Consumer awareness means people willing to pay extra for services that can secure these devices.

    Unfortunately, there is still some ways to go before we have adequate security best practices adopted on a large scale. Governmental agencies or vendor-led organizations might need to implement stricter regulations in order to enable business models that prioritize better security practices. Vendor consortiums could provide one way to resolve the current security crisis, but I suspect that tighter regulations will provide the requisite “teeth” to firmly push the industry in the right direction. In the meantime, I look forward to seeing vendor-supplied solutions that are available to the general public. Let’s hope better awareness prompts some consumers to implement better security.

  • Product Development in the Age of Cloud Native

    Product Development in the Age of Cloud Native

    In defense of the community distribution

    Ever since the mass adoption of Agile development techniques and devops philosophies that attempt to eradication organizational silos, there’s been a welcome discussion on how to optimize development for continuous delivery on a massive scale. Some of the better known adages that have taken root as a result of this shift include “deploy in production after checking in code” (feasible due to the rigorous upfront testing required in this model), “infrastructure as code”, and a host of others that, taken out of context, would lead one down the path of chaos and mayhem. Indeed, the shift towards devops and agile methodologies and away from “waterfall” has led to a much needed evaluation of all processes around product and service delivery that were taken as a given in the very recent past.

    In a cloud native world, where workloads and infrastructure are all geared towards applications that spend their entire life cycle in a cloud environemnt, One of the first shifts was towards lightning fast release cycles. No longer would dev and ops negotiate 6 month chunks of time to ensure safe deployment in production of major application upgrades. No, in a cloud native world, you deploy incremental changes in production whenever needed. And because the dev and test environments have been automated to the extreme, the pipeline for application delivery in production is much shorter and can be triggered by the development team, without needing to wait for a team of ops specialists to clear away obstacles and build out infrastructure – that’s already done.

    Let me be clear: this is all good stuff. The tension between dev and ops that has been the source of frustration over the centuries has left significant organizational scar tissue in the form of burdensome regulations enforced by ops teams and rigid hierarchies which serve to stifle innovation and prevent rapid changes. This is anathema, of course, to the whole point of agile and directly conflicts with the demands of modern organizations to move quickly. As a result, a typical legacy development pathway may have looked like this:

    Screen Shot 2017-05-19 at 9.27.45 AM
    3-stage development process, from open source components to 1st software integration to release-ready product

    In the eyes of agile adherents, this is heretical. Why would you waste effort creating release branches solely for the purpose of branching again and going through another round of testing? This smacks of inefficiency. In a cloud native world, developers would rather cut out the middle step entirely, create a better, comprehensive testing procedure, and optimize the development pipeline for fast delivery of updated code. Or as Donnie Berkholz put it: this model implies waterfall development. What a cloud native practitioner strives for is a shortened release cycle more akin to this:

    Screen Shot 2017-05-19 at 10.20.03 AM
    2-stage process, from open source components to deployable product

    Of course, if you’ve read my series about building business on open source products and services, you’ll note that I’m a big advocate for the 3-step process identified in figure 1. So what gives? Is it hopelessly inefficient, a casualty of the past, resigned to the ash heap of history? I’ll introduce a term here to describe why I firmly believe in the middle step: orthogonal innovation.

    Orthogonal Innovation

    In a perfect world, innovation could be perfectly described before it happens, and the process for creating it would take place within well-defined constructs. The problem is that innovation happens all the time, due to the psychological concept of mental incubation, where ideas fester inside the brain for some indeterminate period of time, until finding its way into a conscious state, producing an “Aha!” moment. Innovation is very much conjoined with happenstance and timing. People spawn innovative ideas all the time, but the vast majority of them never take hold.

    As I wrote in It Was Never About Innovation, the purpose of communities created around software freedom and open source was never to create the most innovative ecosystems in human history – that was just an accidental byproduct. By creating rules that mandated all parties in an ecosystem were relative equals, the stage was set for massively scalable innovation. If one were to look at product lifecycles solely from the point of view of engineering efficiency, then yes, the middle piece of the 3-stage pathway looks extraneous. However, the assumption made is that a core development team is responsible for all necessary innovation, and none more is required. That model also assumes that a given code base has a single purpose and a single customer set. I would argue that the purpose of the middle stage is to expose software to new use cases and people that would have a different perspective from the primary users or developers of a single product. Furthermore, once you expose this middle step to more people, they need a way to iterate on further developments for that code base – developments that may run contrary to the goals of the core development team and its customers. Let’s revisit the 3-stage process:

    Screen Shot 2017-05-19 at 10.48.43 AM

    In this diagram, each stage is important for different reasons. The components on the left represent raw open source supply chain components that form the basis for the middle stage. The middle stage serves multiple entities in the ecosystem that springs up around the code base and is a “safe space” where lots of new things are tried, without introducing risk into the various downstream products. You can see echoes of t his in many popular open source-based products and services. Consider the Pivotal Cloud Foundry process, as explained by James Watters in this podcast with Andreessen Horowitz: raw open source components -> CloudFoundry.org -> Pivotal Cloud Foundry, with multiple derivatives from CloudFoundry.org, including IBM’s.

    As I’ve mentioned elsewhere, this also describes the RHEL process: raw components -> Fedora -> RHEL. And it’s the basis on which Docker is spinning up the Moby community. Once you’ve defined that middle space, there are many other fun things you can do, including building an identity for that middle distribution, which is what many open source communities have formed around. This process works just as well from an InnerSource perspective. Except in that case, the downstream products’ customers are internal, and there are multiple groups within your organization deriving products and services from the core code base in the middle stage. Opening up the middle stage to inspection and modification increases the surface area for innovation and gives breathing room for the more crazy ideas to take shape, possibly leading to their becoming slightly less crazy and useful for the other downstream participants.

    For more on this, come to our meetup at the Microsoft NERD center in Cambridge, MA on May 23, where I’ll present on this subject.

    Addendum: none of the above necessitates a specific development methodology. It could be agile, waterfall, pair programming or any other methodology du jour – it’s immaterial. What matters is constructing a process that allows for multiple points of innovation and iterative construction, even – or especially – where it doesn’t serve the aims of a specific downstream product. You want a fresh perspective, and to get that, you have to allow those with different goals to participate in the process.

  • Open Source Product Management Talk – Slides and Video

    Product Management in Open Source can be an overlooked topic. Asking questions to define what open source really is, its overall value to a product and what options there are when attempting to scale a project can enable a product to grow with minimal pains. This presentation is an overview on the topic and its details.

    [slideshare id=75831384&doc=dannyrosen-opensourceproductmanagement-170509214312]

    [youtube https://www.youtube.com/watch?v=XPeCQNiKkbc]

  • Dear CIO Mag: 2005 called, wants its article back

    I can’t believe that journalists still, despite a wealth of resources at their fingertips, continue to get the story completely wrong about building a business on open source software. I’ve never met Paul Rubens, but he should never be allowed to write on the subject again. Witness his article “How to Make Money From Open Source Software“.

    But how easy is it really to establish an open source startup that makes money? For every success story like Red Hat there are companies like Cyanogen that fail to thrive  and projects that are abandoned.

    That’s in the opening paragraph and is a pretty unsatisfactory way to begin an article. He comes out assuming that making a business or product on open source software is somehow different from any other effort to create a business. Spoiler alert: it’s hard. There’s a reason most startups, open source or otherwise, fail. It’s just not an easy thing to do. This is why we worship the successful founders and their companies (sometimes undeservedly). Because they succeeded where so many other smart, capable people failed. And then he immediately goes to a comparison between Red Hat and Cyanogen, 2 things which couldn’t be more different and weren’t using the same product or business model.

    I’ve said it before: this idea that Red Hat is some magic unicorn whose success cannot be repeated is entirely fallacious. It’s not that Red Hat’s model can’t be repeated, it’s that no one else has even tried.

    Rubens then goes on to quote Sam Byers from Balderton Capital (Why? We’re never told why we should listen to this person, other than he’s a VC dude. Balderdash, I say):

    It’s tempting to believe that the Red Hat business model, which is based around selling subscriptions for support to a maintained and tested version of Linux (or a closely related model that offers consultancy and customization to an open source software solution as well support and maintenance), is the most viable way to make money from open source software. But Sam Myers, a principal at Balderton Capital, a technology venture capital company, says that most open source startups are unlikely to succeed using these business models.

    Here is Rubens setting up the non-point that Red Hat is a magic unicorn, unseen in the wild. What’s wrong here? He gets the model entirely wrong. Red Hat doesn’t sell “subscriptions for support”. Red Hat sells a product, of which one feature is risk reduction and support. This is a common mistake, and it’s very irritating that it’s still made in 2017.

    “Despite Red Hat, it is actually quite challenging to make money selling customization, support and consultancy,” Myers says. “Why? Because it is head-count driven, the model doesn’t scale, and you get low renewals. And you have competition from other consultancies.”

    Newsflash: this is not what Red Hat sells. Again, Red Hat sells a product, that customers buy. Because it delivers value to them. They are not consultants. Can these people read? Do they actually talk to Red Hat customers? But wait, it gets worse:

    Myers admits that the subscription model can occasionally be successful, but asserts that a more promising business model is to build a product line around an open source core. This can involve developing premium software modules that add features to the core open source software or, alternatively, building supporting applications that complement the core.

    Dear God. This is the open core model. It is a highly unsuccessful model, despite repeated efforts over the years to try it. Most sane people came to understand its limitations years ago. Unfortunately, some VC’s still push startups to this approach because it allows them to maintain tighter control over the IP, because they make the mistake of equating code to product. Incidentally, it’s the failure of the open core model that has led some VC’s to simply not invest in open source startups, which is a tragedy.

    Rubens does manage to get in a quote from Allison Randal, which is the only intelligent part of this article:

    …there is no “best” open source business model, and Allison Randal, president of the Open Source Initiative, says that open source startups should avoid searching for one. “The mistake people make is thinking about an open source business model. They should be thinking about a business model and how open source software fits into that,” she says. “VCs are only beginning to understand open source and how to make money, but the way is the same as for any other business: by offering better value and making customers happy. “

    This is what you call “burying the lede.” This is the only takeaway worth taking away from the entire article. Unfortunately, Rubens sets it up as the secondary source. He would have done much better to base the majority of the article on her years of experience building open source communities and products. Randal went on to note the difference between upstream communities and downstream product management:

    Randal says that while most communities don’t mind a company trying to monetize a project, it is key that the community still has a life of its own — in the way that Red Hat has fostered the Fedora community. “What drives a community away is when you take the wind out of its sails and it feels taken over,” she says. Randal adds that little things can make a big difference:  if Cyanogen Inc. had chosen a different name (in place of Cyanogen OS) for its commercial product, which was based on the Cyanogen Mod project, then the community may not have felt so offended by it, she says.

    Exactly. This isn’t hard. On the other hand, there must be something very counter-intuitive about it, because very few actually get it.

    My question to Rubens would be, there are many many people who have spent many years in the trenches building open source products and processes. Why didn’t you base the article on their experience? It’s 2017 for Pete’s sake. Why can’t we discuss this intelligently?

     

  • How to Make Money with Open Source Platforms

    I wrote this 4-part series at linux.com in mid-2015 about creating products based on open source platforms, and how to provide value to a paying customer. The response was great! Read for yourself below:

    In the above series, you’ll read about different product-based business models and which are best, as well as which are not. You’ll read about the difference between “open core” and other viable types of open source-based products. But mostly, you’ll read about the inherent value of open source platforms and how customers will pay to manage their risk.