Planet JM

Category: commentary

  • Whither the OSPO?

    Whither the OSPO?

    I read Dirk Riehle’s recent post on the OSPO Lifecycle, and it conjured up some thoughts that I’ve had recently and have been meaning to write down. Something has been bothering me about the concept of Open Source Program Offices (OSPOs) within corporations and where they fit in value stream discussions, especially since a few OSPOs suffered waves of layoffs and saw a reduction in scope. As a professional OSPO guy, it certainly turned my head and made me think. In Dirk’s post, he points out that the OSPO provides an important leadership function, mostly at the start. Over time, as the company’s open source involvement matures, the OSPO reaches an inflection point and transitions from a thought leadership role to one of coordination and support. The mature OSPO performs a support function for open source governance and compliance, as well as procedural guidance for the few lucky engineers who get to actively participate in external communities. This makes sense if you think of the OSPO as an atomic entity, riding a 5-year lifecycle from inception to “business as usual”.

    But what if OSPOs are not atomic entities? When I think about how OSPOs function, what is often missed is its role in developer productivity. Back when OSPOs were first stood up inside tech vendors, before they were even called OSPOs, a big incentive was vendors wanting to capture value from software produced by collaborative communities. Vendors wanted to be able to reliably use community-produced software embedded within products that they sold. This required a different view of supply chain and product management than had ever existed before, and OSPOs were the chosen vehicle for doing so. Along the way, these vendors discovered that an additional source of value was learning how to collaborate in an open source way. Suddenly, they weren’t just pulling software down from communities, they were actively collaborating with these communities. What OSPOs helped vendors achieve was producing products using the principles of open source collaboration. To me, the enablement of community collaboration and the embrace of open source principles was always the primary value of an OSPO. In that light, to constrain the scope of an OSPO to one of coordination and support is to miss the primary opportunities for value.

    What’s in a Name?

    I think a maturing OSPO needs a name that reflects its aspirational scope. If the ultimate value of an OSPO is measured in developer productivity, then perhaps what’s holding it back is the name. A “program office” may seem like an interesting place to invest if you’re a tech vendor, but the words “program office” have a very different meaning inside large enterprises, one largely associated with bureaucratic functions.

    One of the messages I have incorporated into a lot of my talks since 2013 is that open source communities have been the greatest source of innovation for over two decades, going back to the linux boom of the late 90’s. Any large enterprise would do well to at least attempt to replicate the success of open source communities and instill open source principles into its engineering teams. And if you can expand your “shift left” methodologies to include open source supply chains in your SDLC, then you benefit direclty from the innovation produced by these communities. This is where an OSPO can add the most value, if that value is recognized and invested in. I don’t know that the name necessarily should be, but since accelerated innovation and higher developer productivity are the end goals, then that should be reflected.

    I think when OSPOs grow up, they should become Centers of Innovation and Developer Productivity. Let’s face it, the term “open source” doesn’t grab people like it used to. It became what we always thought it would be – a means to an end. A tool. Instead, let’s focus on the outcome we’re looking to drive: Innovation and Developer Productivity.

  • Why is This Site Called Pro-Life?

    You may have noticed the name of this blog and wondered what this is all about. Am I going to scream at you that abortion is murder and stopping the baby killers? No. Well… unless the subject is infant and maternal mortality in the United States, in which case I will tell you that our terrible racist healthcare “system” and lack of reproductive rights does in fact put babies, and their mamas, at risk. The United States leads the industrialized world in infant and maternal mortality, and not in a good way.

    There are a number of reasons why this is the case:

    • Lack of comprehensive health care – the US leads the world in bankruptcies from illness
    • Rampant poverty, especially among younger women of color of childbearing age
    • High rates of unwanted pregnancies (for a number of reasons – will go into detail in a future blog post)
    • Relatively poor health: high rates of diabetes and other chronic debilitating health issues as well as lowest life expectancy of industrialized countries
    • Lack of prenatal care (will address this in the future – know that this is connected to the US’ overall rejection of reproductive rights for women)

    In every point made above, there is a readily available solution. In fact, every other industrialized nation has solved this problem, and it would be relatively easy for the US to address these issues. The irony is that those most opposed to abortion – those with the gall to call themselves “pro-life” – have resisted every opportunity to address any of the above issues. Every. Single. Time. In fact, they are the ones most vehemently opposed to addressing these problems. Sickening, no? Isn’t it odd that those who call themselves “pro-life” are actually ensuring that more women and children die?

    One of the reasons I started this blog and named it “We Are Pro-Life” is because we, those of us who actually care about people in our communities, we are the real pro-life advocates. We are the ones who advocate for trans lives. We are the ones who defend black lives. We are the ones with the core belief that everyone is equal in the eyes of our creator.

    We. Are. Pro. Life.

    Not those other clowns.

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

  • Open Source and SaaS

    Now that I work in an engineering environment tailored for SaaS development, I’ve developed a better understanding of the challenges they face when open sourcing their code. I wrote it up for OpenSource.com in a 2-part article, “How to decide whether to open source your SaaS solution.”

    Some tidbits:

    The decision to open source code requires a fair bit of planning if you want to do it right, especially when it comes to user support and documentation. In the case of SaaS, the required planning is different, although it shares some factors with any open source effort. In my series, How to Make Money from Open Source Platforms, I focused on software that exists solely to be deployed on a computer, whether on a local machine, in a data center, or in a cloud platform (yes, I know the last two are redundant).

    There was a simple reason for this focus: It was what I knew. In my career, I have always worked with software, of commercial and community origins, to be installed somewhere. Now I work directly with engineers who take software designed to work solely on their website and with their particular infrastructure, automation, and orchestration. The fact they have been able to take this software and offer it to others in a way that is not only usable but can actually power other businesses is a testament to their commitment to an open source world.

    This article attempts to summarize their experience and point out lessons to draw from it. I’ll also try to identify how open source efforts relate to business and product strategy for SaaS models.

    I try to go into some level of detail, using my favorite tool: supply chain funnel analysis. If you’re looking into taking your SaaS code open source, I hope this helps you.

    Read the full article. 

  • TechRepublic: Open Source and Corporate Funding

    I have more to say about this. See the original article on TechRepublic.

    Basic argument goes like this, “individual developers working in their mom’s basement no longer drive open source development! Now it’s all about the corporate $$$$.” My initial thought is “duh”. I’ve always felt that the narrative about a decentralized army creating amazing software that undermined large vendors was entirely wrong. So it’s not that open source is “increasingly” about corporate funding – it was *always* about corporate funding. And as I’ve mentioned elsewhere, open source is not free software. Free software, also known as software freedom, has been about the rights of individual developers and users against the IP cabal of the TIC (techno industrial complex). Open source was about, “yeah, that’s great – but how can I profit from that?”

    So congrats to TechRepublic for being about 15 years behind. I guess?

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

  • DevOps is not enough

    Or: My source code is your platform, and vice-versa.

    https://twitter.com/i/moments/897859467529912321

    https://twitter.com/johnmark/status/897837253946466304

  • It’s the Ecosystem, Stupid

    It’s the Ecosystem, Stupid

    I published a bit over at OpenSource.com.

    Read the full article here.

    It’s a plea to look externally and figure out how your technology relates to all that’s happening in the greater ecosystem. There are still way too many companies who suffer from NIH and end up saddled with way too much technical debt. Don’t do that. Take the time and effort to make inroads into all those communities that are making all the new innovations.

     

     

  • Avoiding Unnecessary Risk – Rules for CEO’s

    Found an interesting article at “The C Suite” on the topic “CEO’s ignorance of open source software use places their business at risk“. While some of the article is a bit “FUDdy” – the author works for a company that sells risk management and mitigation, so there’s a greatest hits of open source vulnerabilities – there were also some eye-opening bits of data. To wit:

    As much as 50 percent of the code found in most commercial software packages is open source.  Most software engineers use open source components to expedite their work – but they do not track what they use, understand their legal obligations for using that code, or the software vulnerability risk it may contain.

    We all know that developers use whatever’s available and don’t ask permission. That is not a surprise. What stood out to me was that the amount of open source code in commercial software was anywhere near 50%. Holy moly. That’s a lot of things to keep track of. When I first started this site, I had an inkling that pretty much all products consume some open source code, and I thought there should be some discussion around best practices for doing so, but I had no idea it was that pervasive. Even I, open source product person, am surprised sometimes by the near ubiquity of open source software in commercial products.

    I think we’re moving beyond simply using open source software. I think we’ll see a  marked shift towards optimization of usage and figuring out models to justify participation and collaboration. At least, that’s my hope. Look for more thoughts on this very subject coming up on this site soon.

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