Tag: docker

  • Inaugural Bay Area Meetup – Aug 3

    Inaugural Bay Area Meetup – Aug 3

    We’re coming to San Francisco! Thanks to Docker for agreeing to host us as we convene in their SOMA headquarters on August 3, 2017. Featured speakers are Stephen Wall, Jono Bacon and yours truly – more to come!

    Agenda

    Join us for our inaugural Open Source Entrepreneur Network meetup in the Bay Area. This meetup will feature the following speakers:

    Stephen Walli: former Microsoft and Outercurve open source executive, currently Docker’s open source strategist

    Stephen will talk about “There is no Open Source Business Model”

    John Mark Walker: long-time open source product, ecosystem and community expert and founder of the Open Source Entrepreneur Network

    John Mark will present a talk on “How to Utilize a Community Distribution in a Cloud Native Context”

    Jono Bacon: Founder of the Community Leadership Summit, author of The Art of Community, and now the founder of Jono Bacon Consulting

    Jono will talk about “Building an Effective Community Strategy”

  • Podcast: Stephen Walli and Rikki Endsley

    Stephen and Rikki stopped by the OSEN studios (haha) to talk about open source trends, product management, and why is there only one Red Hat.

     

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

    Rikki Endsley is the guru who runs the community for OpenSource.com – and does a whale of a job. Stephen is an open source engineering consultant at Docker and blogs for OSEN and at Medium

  • An Open Letter to Docker About Moby

    Congratulations, Docker. You’ve taken the advice of many and gone down the path of Fedora / RHEL. Welcome to the world of upstream/downstream product management, with community participation a core component of supply chain management. You’ve also unleashed a clever governance hack that cements your container technology as the property of Docker, rather than let other vendors define it as an upstream technology for everyone. Much like Red Hat used Fedora to stake its claim as owner of an upstream community. I’ll bet the response to this was super positive, and everyone understood your intent perfectly! Oh…

    So yes, the comparison to Fedora/RHEL is spot on, but you should also remember something from that experiment: at first, everyone *hated* it. The general take from the extended Linux community at the time was that Red Hat was abandoning community Linux in an effort to become “the Microsoft of Linux”. Remember, this level of dissatisfaction is why CentOS exists today. And the Fedora community rollout didn’t exactly win any awards for precise execution. At first, there was “Fedora Core”, and it was quite limited and not a smashing success. This was one of the reasons that Ubuntu became as successful as it did, because they were able to capitalize on the suboptimal Fedora introduction. Over time, however, Red Hat continued to invest in Fedora as a strategic community brand, and it became a valuable staging ground for leading edge technologies from the upstream open source world, much like Moby could be a staging area for Docker.

    But here’s the thing, Docker: you need to learn from previous mistakes and get this right. By waiting so long to make this move, you’ve increased the level of risk you’re taking on, which could have been avoided. If you get it wrong, you’re going to see a lot of community pressure to fork Moby or Docker and create another community distribution outside of your sphere of influence. The Fedora effort frittered away a lot of good will from the Linux community by not creating an easy to use, out of the box distribution at first. And the energy from that disenchantment went to Ubuntu, leaving Fedora in a position to play catchup. That Red Hat was able to recover and build a substantial base of RHEL customers is a testament to their ability to execute on product management. However, Ubuntu was able to become the de facto developer platform for the cloud by capitalizing on Fedora’s missteps, putting them on the inside track for new cloud, IoT, and container technologies over the years. My point is this: missteps in either strategy and execution have a large and lasting impact.

    So listen up, Docker. You need to dedicate tremendous resources right now to the Moby effort to make sure that it’s easy to use, navigate, and most importantly, ensure that your community understands its purpose. Secondly, and almost as importantly, you need to clearly communicate your intent around Docker CE and EE. There is no room for confusion around the difference between Moby and Docker *E. Don’t be surprised if you see a CentOS equivalent to Docker CE and/or EE soon, even though you’re probably trying to prevent that with a freely available commercial offering. Don’t worry, it will only prove your model, not undermine it, because no one can do Docker better than Docker. Take that last bit to heart, because far too many companies have failed because they feared the success of their free stuff. In this case, that would be a colossal unforced error.

     

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