Planet JM

Category: syndicate

  • There is No Open Source Community

    There is No Open Source Community

     

    In January, 2006, I published this article on O’Reilly’s OnLAMP.com site, which was recently shut down. I’ve always been proud of this essay, because I think I got a lot right.  I’m republishing it now in the hopes that it will continue to educate others – and perhaps  allow others to critically evaluate where I fell short in my arguments.  The central thesis is here:

    The commoditization of software and a gradual, long-term reduction in price have played far more important roles than previously recognized. Business strategy designed to leverage open source should focus more on economies of scale (in terms of user and developer bases) and less on pleasing a mythical, monolithic community.

    Basically, stop treating open source as a social movement, because it’s not. This false assumption has caused much harm to software developers and users alike (more on that in a follow-up article). However, while I’m busy patting myself on the back for writing about software commoditization, I missed something fairly big: the value of source code itself is essentially worthless. This may have actually been more important than the price of software.

  • Podcast: Shane Coughlan of Openchain

    Podcast: Shane Coughlan of Openchain

    Shane Coughlan is the founder and manager of the Openchain Project, which “builds trust in open source by making open source license compliance simpler and more consistent.” As any software asset management person can tell you, they get cross-eyed when it comes to open source license compliance. My opinion has always been that this was due to lack of information outside of the immediate sphere of open source developers. The Openchain Project aims to remedy that, and in this podcast we talked about the challenges of doing that. It’s a great listen!

  • 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.

  • 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.

  • Red Hat’s Secret Sauce

    This is a guest post by Paul Cormier, President, Products and Technologies, Red Hat. It was originally posted on the Red Hat blog.

    Open source software is, in fact, eating the world. It is a de facto model for innovation, and technology as we know it would look vastly different without it. On a few occasions, over the past several years, software industry observers have asked whether there will ever be another Red Hat. Others have speculated that due to the economics of open source software, there will never be another Red Hat. Having just concluded another outstanding fiscal year, and with the perspective of more than 15 years leading Red Hat’s Products and Technologies division, I thought it might be a good time to provide my own views on what actually makes Red Hat Red Hat.

    Commitment to open source

    Red Hat is the world’s leading provider of open source software solutions. Red Hat’s deep commitment to the open source community and open source development model is the key to our success. We don’t just sell open source software, we are leading contributors to hundreds of open source projects that drive these solutions. While open source was once viewed as a driver for commoditization and driving down costs, today open source is literally the source of innovation in every area of technology, including cloud computing, containers, big data, mobile, IoT and more.

    Red Hat is best known for our leadership in the Linux communities that drive our flagship product, Red Hat Enterprise Linux, including our role as a top contributor to the Linux kernel. While the kernel is the core of any Linux distribution, there are literally thousands of other open source components that make up a Linux distribution like Red Hat Enterprise Linux, and you will find Red Hatters, as well as non-Red Hatters, leading and contributing across many of these projects. It’s also important to note that Red Hat’s contributions to Linux don’t just power Red Hat Enterprise Linux, but also every single Linux distribution on the planet – including those of our biggest competitors. This is the beauty of the open source development model, where collaboration drives innovation even among competitors.

    Today, Red Hat doesn’t just lead in Linux, we are leaders in many different communities. This includes well-known projects like the docker container engine, Kubernetes and OpenStack, which are among the fastest growing open source projects of the last several years. Red Hat has been a top contributor to all of these projects since their inception and brings them to market in products like Red Hat Enterprise Linux, Red Hat OpenShift Container Platform and Red Hat OpenStack Platform. Red Hat’s contributions also power competing solutions from the likes of SUSE, Canonical, Mirantis, Docker Inc., CoreOS and more.

    The list of communities Red Hat contributes to includes many more projects like Fedora, OpenJDK, Wildfly, Hibernate, Apache ActiveMQ, Apache Camel, Ansible, Gluster, Ceph, ManageIQ and many, many more. These power Red Hat’s entire enterprise software portfolio. This represents thousands of developers and millions of man-hours per year that Red Hat commits to the open source community. Red Hat also commits to keeping our commercial products 100% pure open source. Even when we acquire a proprietary software company, we commit to releasing all of its code as open source. We don’t believe in open core models, or in being just consumers but not contributors to the projects we depend on. We do this because we still believe in our core that the open source development model is THE best model to foster innovation, faster.

    As I told one reporter last week, some companies have endeavored to only embrace ‘open’ where it benefits them, such as open core models. Half open is half closed, limiting the benefits of a fully open source model. This is not the Red Hat way.

    This commitment to contribution translates to knowledge, leadership and influence in the communities we participate in. This then translates directly to the value we are able to provide to customers. When customers encounter a critical issue, we are as likely as anyone to employ the developers who can fix it. When customers request new features or identify new use cases, we work with the relevant communities to drive and champion those requests. When customers or partners want to become contributors themselves, we even encourage and help guide their contributions. This is how we gain credibility and create value for ourselves and the customers we serve. This is what makes Red Hat Red Hat.

    Products not projects

    Open source is a development model, not a business model. Red Hat is in the enterprise software business and is a leading provider to the Global 500. Enterprise customers need products, not projects and it’s incumbent on vendors to know the difference. Open source projects are hotbeds of innovation and thrive on constant change. These projects are where sometimes constant change happens, where the development is done. Enterprise customers value this innovation, but they also rely on stability and long-term support that a product can give. The stable, supported foundation of a product is what then enables those customers to deliver their own innovations and serve their own customers.

    Too often, we see open source companies who don’t understand the difference between projects and products. In fact, many go out of their way to conflate the two. In a rush to deliver the latest and greatest innovations, as packaged software or public cloud services, these companies end up delivering solutions that lack the stability, reliability, scalability, compatibility and all the other “ilities” or non-functional requirements that enterprise customers rely on to run their mission-critical applications.

    Red Hat understands the difference between projects and products. When we first launched Red Hat Enterprise Linux, open source was a novelty in the enterprise. Some even viewed it as a cancer. In its earliest days, few believed that Linux and open source software would one day power everything from hospitals, banks and stock exchanges, to airplanes, ships and submarines. Today open source is the default choice for these and many other critical systems. And while these systems thrive on the innovation that open source delivers, they rely on vendors like Red Hat to deliver the quality that these systems demand.

    Collaborating for community and customer success

    Red Hat’s customers are our lifeblood. Their success is our success. Just like we thrive on collaboration in open source communities, that same spirit of collaboration drives our relationships with our customers. By using open source innovation, we help customers drive innovation in their own business. We help customers consume the innovation of open source-developed software. Customers appreciate our willingness to work with them to solve their most difficult challenges. They value the open source ethos of transparency, community and collaboration. They trust Red Hat to work in their best interests and the best interests of the open source community.

    Too often open source vendors are forced to put commercial concerns over the interests of customers and the open source communities that enable their solutions. This doesn’t serve them or their customers well. It can lead to poor decision making in the best case and fractured communities in the worst case. Sometimes these fractures are repaired and the community emerges stronger, as we saw recently with Node.js. Other times, when fractures are beyond repair, new communities take the place of existing ones, as we have seen with Jenkins and MariaDB. Usually, we see that open source innovation marches forward, but this fragmentation only serves to put vendors and their customers at risk.

    Red Hat believes in collaborating openly with both customers and the open source community. It’s that collaboration that brings forward new ideas and creative solutions to the most difficult problems. We work with the community to identify solutions and find common ground to avoid fragmentation. Through the newly launched Red Hat Open Innovation Labs we are bringing that knowledge and experience directly to our customers.

    The next Red Hat

    Will there be another Red Hat? I hope and expect that there will be several. Open source is now the proven methodology for developing software. The days of enterprises relying strictly on proprietary software has ended. The problems that we have to solve in the complexities of today’s world are too big for just one company. Vendors may deliver solutions in different ways, address different market needs and/or serve different customers – but I believe that open source will be at the heart of what they do. We see open source at the core of leading solutions from both the major cloud providers and leading independent software vendors. But, open source is a commitment, not a convenience, and innovative open source projects do not always lead to successful open source software companies.

    Today, we strive not only to be the Red Hat of Linux, but also the Red Hat of containers, the Red Hat of OpenStack, the Red Hat of middleware, virtualization, storage and a whole lot more. Many of these businesses, taken independently, would be among the fastest growing technology companies in the world. They are succeeding because of the strong foundation we’ve built with Red Hat Enterprise Linux, but also because we’ve followed the same Red Hat Enterprise Linux playbook of commitment to the open source community, knowing the difference between products and projects, and collaborating for community and customer success – across all of our businesses. That’s what makes us Red Hat.

  • There is NO Open Source Business Model

    Note: the following was first published on medium.com by Stephen Walli. It is reprinted here with his permission.

    Preface: It has been brought to my attention by friends and trusted advisors that a valid interpretation of my point below is that open source is ultimately about “grubby commercialism”, and altruism equals naïveté. That was not my intent. I believe that economics is about behaviour not money. I believe in Drucker (a company exists to create a market for the solution), not Friedman (a company exists to provide a return to shareholders). I believe in the Generous Man. I believe in Rappaport’s solution to the Prisoner’s Dilemma to always start with the most generous choice. I believe we’ve known how communities work since you had a campfire and I wanted to sit beside it. I had the pleasure of watching Bob Young give a talk today at “All Things Open” where he reiterated that a successful company always focuses on the success of its customers. I think that was stamped on Red Hat’s DNA from its founding, and continues to contribute to its success with customers today. I believe sharing good software is the only way to make all of us as successful as we can be as a tribe. I believe there is no scale in software without discipline.

    The open source definition is almost 20 years old. Red Hat at 22 is a $2B company. MySQL and JBoss have had great acquisition exits. Cloudera and Hortonworks are well on their way to becoming the next billion dollar software companies. But I would like to observe that despite these successes, there is no open source business model.

    yosuke muroya (on Flickr)

    I completely believe in the economic value of liberally-licensed collaboratively-developed software. We’ve shared software since we’ve developed software, all the way back into the late 40s and early 50s. This is because writing good software is inherently hard work. We’ve demonstrated that software reviews find more bugs than testing, so building a software development culture of review creates better software. Much of the invention in software engineering and programming systems has been directed towards re-use and writing more and better software in fewer lines of code. Software can’t scale without discipline and rigour in how it’s built and deployed. Software is inherently dynamic, and this dynamism has become clear in an Internet connected world. Well-run, disciplined, liberally-licensed collaborative communities seem to solve for these attributes of software and its development better than other ways of developing, evolving, and maintaining it. There is an engineering economic imperative behind open source software.

    Here’s an example using open source that I believe closely demonstrates that reality.

    Interix was a product in the late 90s that provided the UNIX face on Windows NT. It encompassed ~300 software packages covered by 25 licenses, plus a derivative of the Microsoft POSIX subsystem, plus our own code. This was before the open source definition. We started with the 4.4BSD-Lite distro because that’s what the AT&T/USL lawyers said we could use. The gcc compiler suite would provide critical support for our tool chain as well as an SDK to enable customers to port their UNIX application base to Windows NT.

    It took a senior compiler developer on the order of 6–8 months to port gcc into the Interix environment. It was a little more work when you include testing and integration, etc., so round it up to on the order of $100K. The gcc suite was about 750K lines of code in those days, which the COCOMO calculation suggests was worth $10M-$20M worth of value depending on how much folks were earning. So that’s roughly two orders of magnitude in cost savings instead of writing a compiler suite on our own. That and this was a well-maintained, robust, hardened compiler suite, not a new creation created from scratch in a vacuum. That is the benefit of using open source. You can see a similar net return on the 10% year-on-year investment Red Hat makes on their Linux kernel contributions as they deliver Fedora and RHEL. Of course with Interix, we were now living on a fork. This means we are drifting further away from the functionality and fixes on the mainline.

    The back of the envelop estimate suggested that every new major revision of gcc would cost us another 6+ months to re-integrate, but if we could get our changes contributed back into the mainline code base, we were probably looking at a month of integration testing instead. So from ~$100K we’re approaching $10K-$20K so possibly another order of magnitude cheaper by not living on a fork. We approached Cygnus Solutions as they were the premier gcc engineering team with several gcc committers. The price to integrate quoted to us was ~$120K, but they were successfully oversubscribed with enough other gcc work that they couldn’t begin for 14 months. Ada Core Technologies on the other hand would only charge ~$40K and could begin the following month. It was a very easy decision. (We were not in a position to participate directly in the five communities hiding under the gcc umbrella. While some projects respected the quality of engineering we were trying to contribute, others were hostile to the fact we were working on that Microsoft s***. There’s no pleasing some people.)

    This wasn’t contributing back out of altruism. It was engineering economics. It was the right thing to do, and contributed back to the hardening of the compiler suite we were using ourselves. It was what makes well run open source projects work. I would argue that individuals make similar decisions because having your name on key contribution streams in the open source world is some of the best advertising and resume content you can provide as a developer on your ability to get work done, in a collaborative engineering setting, and demonstrating you well understand a technology base. It’s the fact with which you can lead in an interview. And it’s fun. It’s interesting and challenging in all the right ways. If you’re a good developer or interested in improving your skills, why wouldn’t you participate and increase your own value and skills?

    Well run open source software communities are interesting buckets of technology. If they evolve to a particular size they become ecosystems of products, services (support, consulting, training), books and other related-content. To use an organic model, open source is trees, out of which people create lumber, out of which they build a myriad of other products.

    Red Hat is presented as the epitome of an open source company. When I look at Red Hat, I don’t see an open source company. I see a software company that has had three CEOs making critical business decisions in three different market contexts as they grow a company focused on their customers. Bob Young founded a company building a Linux distro in the early days of Linux. He was focused on the Heinz ketchup model of branding. When you thought “Linux”, Bob wanted the next words in your head to be “Red Hat.” And this was the initial growth of Red Hat Linux in the early days of the Internet and through the building of the Internet bubble. It was all about brand management. Red Hat successfully took key rounds of funding, and successfully went public in 1999. The Red Hat stock boomed.

    Matt Szulick took over the reins as CEO that Fall. Within a couple of years the Internet bubble burst and the stock tumbled from ~$140 down to $3.50. Over the next couple of years, Red Hat successfully made the pivot to server. RHEL was born. Soon after Fedora was delivered such that a Red Hat focused developer community would have an active place to collaborate while Red Hat maintained stability for enterprise customers on RHEL. They successfully crossed Moore’s Chasm in financial services. JBoss was acquired for $350M to provide enterprise middleware. Red Hat went after the UNIX ISV community before the other Linux distro vendors realized it was a race.

    In 2008, Jim Whitehurst took over the helm. In Whitehurst, they had a successful executive that had navigated running an airline through its Chapter 11 restructuring. So he knows how to grow and maintain employee morale, while managing costs, and keeping customers happy in the viciously competitive cutthroat market of a commercial air travel. He arrives at Red Hat just in time for the economic collapse of 2008. Perfect. But he has also led them through steady stock growth since joining.

    Through its history, Red Hat has remained focused on solving their customers problems. Harvard economist Theodore Levitt once observed that a customer didn’t want a quarter inch drill, what they wanted was a quarter inch hole. While lots of competing Linux distro companies tried to be the best Linux distro, Red Hat carefully positioned themselves not as the best Linux but as an enterprise quality, inexpensive alternative to Solaris on expensive SPARC machines in the data centre.

    Red Hat certainly uses open source buckets of technology to shape their products and services, but it’s not a different business model from the creation of DEC Ultrix or Sun SunOS out of the BSD world, or the collaborative creation of OSF/1 and the evolution of DEC Ultrix and IBM AIX, or the evolution of SunOS to Solaris from a licensed System V base. At what point did Windows NT cease to be a Microsoft product with the addition of thousands of third party licensed pieces of software including the Berkeley sockets technology?

    When companies share their own source code out of which they build their products and services, and attempt to develop their own collaborative communities, they gain different benefits. Their technology becomes stickier with customers and potential future customers. They gain advocates and experts. It builds inertia around the technology. The technology is hardened. Depending on the relationship between the bucket of technology and their products, they can evolve strong complements to their core offerings.

    The engineering economic effects may not be as great as pulling from a well run external bucket of technology, but the other developer effects make up for the investment in a controlled and owned community. It’s why companies like IBM, Intel, Microsoft, and Oracle all invest heavily in their developer networks regardless of the fact these historically had nothing to do with open source licensing. It creates stickiness. Red Hat gains different benefits from their engineering investments in Linux, their development of the Fedora community, and the acquisition of the JBoss technology, experts, and customers.

    I believe open source licensed, disciplined, collaborative development communities will prove to be the best software development and maintenance methodology over the long term. It’s created a myriad of robust adaptive building blocks that have become central to modern life in a world that runs on software. But folks should never confuse the creation of those building blocks with the underlying business of solving customer problems in a marketplace. There is no “open source business model.”