Planet JM

Blog

  • “Every evangelist of yesteryear is now a Community Manager ….”

    This post first appeared on Medium. It is reprinted here with permission. 

    OH: “Every evangelist of yesteryear is now a Community Manager … at least on their biz card.”

    This statement best captures a question that comes up regularly in the open source community world when you have corporations involved. Does your community manager report to engineering or marketing? It captures a number of assumptions quite nicely.

    First, the concept of a “community manager” does imply a certain amount of corporate structure regardless of whether it’s for profit or some form of non-profit. If the open source licensed project is in the wild then it probably doesn’t have the size and adoption to require people with such titles. Such well-run project communities are self-organizing. As they grow and there are more things to do than vet code and commit, they accommodate new roles. They may even form council-like sub-organizations (e.g. documentation). But for the most part, the work is in-the-small, and it’s organic. The structure of well run “pre-corporate” projects is in process discipline around such work as contributions, issue tracking, and build management.

    When projects grow and evolve to the point that companies want to get involved, using the project software in their products and services, then the project “property” needs to be protected differently. The software project already has a copyright (because it’s the law) and is covered by an open source license (because that social contract enables the collaboration), but trademarks and provenance can quickly become important. Companies have different risk profiles. A solution to such corporate concerns can be to wrap a non-profit structure around the project. This can mean the project chooses to join an existing foundation like the Apache Software Foundation or the Eclipse Foundation, or it could form its own foundation (e.g. the Gnome Foundation). In return for the perceived added overhead to the original community, it enables company employees to more actively contribute. (The code base for Apache httpd project doubled in the first few months after the ASF formed.)

    A community manager implies more administrative structure and discipline around people coordination for growth, than the necessary software construction discipline that the early project required for growth. But a foundation often brings the sort of administrative structure for events and communications such that folks in the project (or projects) still don’t have a title of “community manager.”

    Community managers are a corporate thing. And I believe they start showing up when either a project becomes a company (e.g. Apache Mesos into Mesosphere), a company wants to create a project or turn a product into a project (e.g. Hewlett Packard Enterprise with OpenSwitch), or a company wants to create a distribution of a project (e.g. Canonical with Ubuntu, Red Hat with Fedora, Cloudera with Apache Hadoop). And this is implied in the original statement about “biz cards” and questions of marketing versus engineering.

    Software companies have long understood developer networks. MSDN, the Oracle Developer Network, and the IBM Developer Network have been around for decades. They are broadcast communities carrying marketing messages to the faithful. They were run by Developer Evangelists and Developer Advocates. MVP programs were created to identify and support non-employees acting in an evangelism role. These networks are product marketing programs. They tightly control access to product engineers, who allowed to appear at conferences and encouraged to write blog posts. These networks are the antithesis of the conversation that is a high functioning open source community.

    I believe companies with long histories building developer networks (or employees that have such experience at new companies) make the mistake of thinking open source “community managers” belong in product marketing. They are probably using the wrong metrics to measure and understand (and hopefully support) their communities. They are falling into the classic trap of confusing community with customer, and project with product.

    Liberally-licensed, collaboratively-developed software projects, (i.e. open source) is an engineering economic imperative. Because of that reality, I believe the community management/enablement role belongs in engineering. If a company is enlightened enough to have a product management team that is engineering focused (not marketing focused), then the community manager fits into that team as well.

    This is a working theory for me, consistent with the successes and failures I’ve observed over the past 25 year. I would love folks feedback, sharing their experiences or expanding upon my observations.

  • Why Project Moby is a Brilliant Move by Docker

    On Tuesday, Solomon Hykes, Docker’s CTO and co-founder, unleashed the Moby Project on the world. I’ll admit I didn’t fully grasp its significance at first. This might have something to do with being on vacation in Cape Cod and not being at DockerCon, but I digress. It wasn’t until I read this Twitter thread from Kelsey Hightower that something clicked:

    And then it dawned on me – Docker was taking a page out of the Red Hat playbook and fully embracing the upstream supply chain model. In 2003, Red Hat decided it needed to focus on enterprise subscriptions and moved away from its free commercial linux, the venerable Red Hat Linux. In its place, Red Hat created Red Hat Enterprise Linux (RHEL), and then a funny thing happened: its employees rebelled and created the Fedora community and project, designed to be a community Linux distribution. This turned out to be a brilliant move. Forward looking technology and innovation happened in the Fedora community, and then it went through a series of hardening, polish, integration with other Red Hat platforms and bug fixes before being released under the RHEL brand. The more complex Red Hat’s product offerings became, the more valuable this model proved.

    Red Hat product supply chain:

    The container ecosystem shares much with the Linux ecosystem, because that’s where it came from. One of the criticisms of Docker, much like Red Hat, is that they’re “trying to control the entire ecosystem”. I may have uttered that phrase from time to time, under my breath. The Moby Project, in my opinion only, is a direct response to that. As Solomon mentioned in his blog announcement:

    In order to be able to build and ship these specialized editions is a relatively short time, with small teams, in a scalable way, without having to reinvent the wheel; it was clear we needed a new approach.

    Yes, any successful ecosystem becomes extremely difficult to manage over time, which is why you end up giving up control, without giving up your value proposition. This is also probably why you’ve seen Docker become more engaged on the CNCF front and why they drove the OCI formation. As David Nalley likes to say, this is the “hang on loosely, but don’t let go” approach to community-building:

    There’s also the branding and trademark benefit. Just as with Fedora and RHEL, separating the branding streams now means that community-minded people know where to go: Project Moby. And prospective customers and partners also know where to go: Docker.com. It’s a great way to let your audiences self-select.

    Docker decided to take the next step and embrace the open source supply chain model. This is a good thing.

  • How Silicon Valley Ruined Open Source Business

    Back in the early days of open source software, we were constantly looking for milestones to indicate how far we had progressed. Major vendor support: check (Oracle and IBM in 1998). An open source IPO: check (Red Hat and VA Linux in 1999). Major trade show: check (LinuxWorld in 1999). And then, of course, a venture-backed startup category: check (beginning with Cygnus, Sendmail, VA, and Red Hat in the late 90’s, followed by a slew of others, especially after the dot bomb faded after 2003). Unfortunately, VC involvement came with a hefty price. And then, of course, our first VC superstar: check (Peter Fenton).

    Remember, this was a world where CNBC pundits openly questioned how Red Hat could make money after they “gave away all their IP”. (spoiler alert: they didn’t. That’s why it’s so funny). So when venture capitalists got into the game, they started inflicting poor decisions on startup founders, mostly centered on the following conceits:

    1. OMG you’re giving away your IP. You have to hold some back! How do you expect to make money?
    2. Here’s a nice business plan I just got from my pal who’s from Wharton. He came up with this brilliant idea: we call it ‘Open Core’!”
    3. Build a community – so we can upsell them!
    4. Freeloaders are useless

    A VC’s view of open source at the time was simplistic and limited mostly to the view that a vendor should be able to recoup costs by charging for an enterprise product that takes advantage of the many stooges dumb enough to take in the free “community” product. In this view, a community is mostly a marketing ploy designed for a captive audience that had nowhere else to go. For many reasons, this is the view that the VC community embraced in the mid-2000’s. My hypothesis: when it didn’t work, it soured the relationship between investors and open source, which manifests itself in lost opportunities to this day.

    What should have been obvious from the beginning – source code is not product – has only recently begun to get airplay. Instead, we’ve been forced to endure a barrage of bad diagnoses of failures and bad advice for startup founders. It’s so bad that even our open source business heroes don’t think you can fully embrace open source if you want to make money. The following is from Mike Olson, mostly known for his business acumen with Cloudera and Sleepycat:

    The list of successful stand-alone open source vendors that emerged over that period is easy to write, because the only company on it is Red Hat. The rest have failed to scale or been swallowed.

    …The moral of that story is that it’s pretty hard to build a successful, stand-alone open source company. Notably, no support- or services-only business model has ever made the cut.

    As I have mentioned early and often, as has Stephen Walli, a project is not a product, and vice-versa, and it’s this conflation of the two that is a profound disservice to startups, developers, and yes, investors. Here’s the bottom line: you want to make money in a tech startup? Make a winning solution that offers value to customers for a price. This applies whether you’re talking about an open source, proprietary, or hybrid solution. This is hard to do, regardless of how you make the sausage. Mike Olson is a standup guy, and I hope he doesn’t take this personally, but he’s wrong. It’s not that “it’s pretty hard to build a successful, stand-alone open source company.” Rather, it’s hard to build a successful stand-alone company in *any* context. But for some reason, we notice the open source failures more than the others.

    The failures are particularly notable for how they failed, and how little has been done to diagnose what went wrong, other than “They gave away all their IP!” In the vast majority of cases, these startups were poorly received because they either a.) had a terrible product or b.) they constrained their community to the point of cutting off their own air supply. There were of course, notable exceptions. While it wasn’t my idea of the best way to do it, MySQL turned out pretty well, all things considered. The point is, don’t judge startups based on their development model; judge them on whether they have a compelling offering that customers want.

    While investors in 2017 are smarter than their 2005 cousins, they still have blinders when it comes to open source. They have distanced themselves from the open core pretenders, but in the process, they’ve also distanced themselves from potential Red Hats. Part of this is due to an overall industry trend towards *aaS and cloud-based services, but even so, any kind of emphasis on pure open source product development is strongly discouraged. If I’m a *aaS-based startup today and I approach an investor, I’m not going to lead off with, “and we’re pushing all of our code that runs our internal services to a publicly-accessible GitHub account!” Unless, of course, I wanted to see ghastly reactions.

    This seems like a missed opportunity: if ever there was a time to safely engage in open source development models while still maintaining your product development speed and agility, using a *aaS model is a great way to do it. After all, winning at *aaS means winning at superior operations and uptime, which has zilch to do with source code. And yet, we’re seeing the opposite: most of the startups that do full open source development are the ones that release a “physical software download” and the SaaS startups run away scared, despite the leverage that a SaaS play could have if they were to go full-throttle in open source development.

    It’s gotten to the point that when I advise startups, I tell them not to emphasize their open source development, unless they’re specifically asked about it. Why bother? They’re just going to be subjected to a few variations on the theme of “but how are you going to get paid?” Better to focus on your solution, how it wins against the competition, and how customers are falling over themselves to get it. Perhaps that’s how it always should have been, but it strikes me as odd that your choice of development model, which is indirectly and tangentially related to how you move product, should be such a determining factor on whether your startup gets funded, even more so than whether you have a potentially winning solution. It’s almost as if there’s an “open source tax” that investors factor into any funding decision involving open source. As in, “sure, that’s a nice product, but ooooh, I have to factor in the ‘open source tax’ I’ll have to pay because I can’t get maximum extraction of revenue.”

    There are, of course, notable exceptions. I can think of a few venture-backed startups with an open source focus. But often the simple case is ignored in favor of some more complex scheme with less of a chance for success. Red Hat has a very simple sales model: leverage its brand and sell subscriptions to its software products. The end. Now compare that to how some startups today position their products and try to sell solutions. It seems, at least from afar, overly complicated. I suspect this is because, as part of their funding terms, they’re trying to overcome their investors’ perceptions of the open source tax. Sure, you can try to build the world’s greatest software supply house and delivery mechanism, capitalizing on every layer of tooling built on top of the base platform. Or you can, you know, sell subscriptions to your certified platform. One is a home run attempt. The other is a base hit. Guess which way investors have pushed?

  • Ask Not What Your Community Can Do For You

    This post first appeared on Medium. It is reprinted here with permission. 

    During his inaugural speech on Jan. 20, 1961, U.S. President John F. Kennedy uttered the challenge, “And so, my fellow Americans: ask not what your country can do for you — ask what you can do for your country.” Its simple meaning was to challenge society to contribute to improve the public good. But I think there’s a bigger message here, and that is that we have to work together as a society to improve our collective state. And because of that, I think the statement has a lot to tell us about community building in general and for open source communities certainly.

    Publishing software with an open source license is the definitive step of creating an open source project. The creation of such collaborative licensing is Richard Stallman’s brilliant hack on the system of copyright law back in the early 1980s. If software is covered by copyright, so a user of the software must honor the copyright by adhering to its license or otherwise asking for permission, then create licenses that say, “do whatever you will with this software, while honoring these clauses in return.” It is the perfect hack on a software copyright system that would otherwise collapse under its own weight when the dynamic nature of software encountered the friction-free publishing channel of the Internet. But while publishing software this way is the definitive step of creating an open source project, it doesn’t create a community.

    While many societal norms and interactions are imposed by a choice of where you live, from the country down to your street address, on the Internet those choices and interactions play out differently. The cost of choosing your online community is far lower in the digital world than the economic friction in the world of bricks and mortar. So is the cost of leaving. As an online community you need to attract folks differently if they’re going to engage. You need to make it easy for the community to do the things they want to do. They aren’t coming to help you build your community, at least not at first. They’re coming because the project (the neighborhood) is interesting to their own needs and goals.

    And there are three sorts of folks that join your community.

    • There are the folks that just want to live there using your software.
    • There are the folks living there that are happy to help in small ways, letting you know where the potholes that they almost hit every day are forming, or about a vacant lot that’s unsafe.
    • And there are the folks living there, that let you know about that vacant lot, and that are happy to help clean it up, contribute a park bench, or organize the neighborhood party to celebrate after the cleanup is done.

    And you need to make it easy in three different ways for those three sorts of folks in your community, because the groups are nested inside one another. People don’t build parks in vacant lots where they don’t live. They’re very unlikely to notice the potholes in a meaningful way if they don’t live on the street. They won’t move into your neighborhood in the first place if its cluttered, unorganized, and doesn’t provide any guidance for where the schools and shops are, or when garbage collection happens and how recycling works there. And they certainly don’t move into neighborhoods in which they can’t afford the costs (in time or money).

    Growing and scaling a successful open source software project requires building three on-ramps: first for users, then for developers, and ultimately for contributors.

    If it is not blindingly easy to download the software, install it to a known state, and use it in some meaningful way, you will not encourage a growing set of neighbors. If the developers in that group of neighbors can’t easily build the software to a known state so they can effect their own changes, then they will look elsewhere for easier to use solutions. They will move out and move on. If you don’t make it easy to contribute those developers’s changes back to the project, it becomes a permanent growing collection of expensive forks that doesn’t harden the way good software projects do.

    In the 1990s, we had a ten-minute rule of thumb for packaged PC software from pulling the shrink-wrap off the box to doing something meaningful. When you download an app to your phone, how long do you work at it until it behaves as advertised or you abandon it? The same sort of thinking needs to apply to your software project users. So to for the developers in that group of users that will want to do things with the project to their own needs. So to for your eventual contributors out of that group of developers.

    Well run successful open source software communities make the costs of using, developing, and contributing to the community easy to bear, and they work to continue to make it easier. Publishing a piece of software on the Internet with an open source license is easy. Growing a community takes work, but the value in the hardened, evolved software for all is easy to see in successful communities. So ask not what your community can do for you, ask what you can do for your community.

  • Updated: OSEN Meetup in Cambridge, MA 4/25

    Update: Red Hat is sponsoring food and drinks, and the CIC is sponsoring meeting space. Our agenda is as follows:

    • 6pm – Introductions, food and drinks
    • 6:30pm – Open Source Business Models, Dave Neary, Red Hat
    • 7pm – From Project to Product, John Mark Walker, Dell EMC and OSEN
    • 7:30pm – Learning from the OpenNebula Example, Ignacio Llorente, OpenNebula

    We just formed a meetup group for the Boston, MA area – read about it at meetup.com.

    So what’s this about? In this first meetup, we’ll talk about taking code from project to product – what do you need to know when undergoing this journey?

    Who should attend:

    • CIOs/CTOs who need to understand dynamics of open source ecosystems and their impact on supply chains

    • Product managers who want to understand modern methods for product development

    • Founders how have a great idea and need to efficiently build on platforms of innovation

    • Investors who want to understand what to look for in their startup portfolio

    • Anyone, anywhere, who wants to take an open source project and build a solution

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

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

     

  • Bitnami Enters Kubernetes, Cloud Native Race

    logo2x-d9b4e58308404c7e986f383f2191084eBitnami has officially entered the highly competitive race for cloud native platforms, acquiring Skippbox and joining the Cloud Native Computing Foundation. To those who have been observing Bitnami over the years, this move is not a surprise. Previously known as the world’s #1 service for launching apps in AWS, it seems a natural move for Bitnami to add app management to its portfolio. From the press release:

    The acquisition of Skippbox isn’t Bitnami’s only investment into the Kubernetes ecosystem. She noted her company has been investing significantly in the Helm project for Kubernetes and has two committers to the project. Helm is a tool for managing Kubernetes Charts, with Charts being packages of pre-configured Kubernetes resources.

    That is what you call “burying the lede.” This is the continuation of a year-long effort to create products in the cloud native application management space. On the same day, Bitnami also announced it joined the CNCF. I think it’s safe to say that Bitnami sees a strong future in Kubernetes-based cloud native management services.

  • Managing Your Supply Chain

    Depending on open source software introduces some challenges for those looking to create products or services derived from upstream open source components. There’s a lot to consider regarding risk management, engineering efficiency, and how to influence the nebulous upstream open source world – and why you should. Original content was published at opensource.com: