Planet JM

Category: commentary

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

     

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

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