Welcome to The Long View—where we peruse the news of the week and strip it to the essentials. Let’s work out what really matters.
This week: SUSE announces a Red Hat Enterprise Linux fork after Oracle said a similar thing, and Sarah Silverman says OpenAI and Meta have stolen her words. (more…)
Welcome to The Long View—where we peruse the news of the week and strip it to the essentials. Let’s work out what really matters.
This week: Red Hat Enterprise Linux (RHEL) goes closed source. Well—no, not really; but IBM’s lawyers are accused of skating so close to the edge of legality that they risk violating the GNU Public License. (more…)
Welcome to The Long View—where we peruse the news of the week and strip it to the essentials. Let’s work out what really matters.
This week: Sources say it’s an open source future for OpenAI, and improving AI perf with Mojo. (more…)
Over the years, what we purchase from vendors has changed significantly. It used to be that IT would define a need, go out and find a bit of software to solve it, install and configure the software and, in most cases, spend the majority of time on the project getting it to work correctly in their environment. Those days are largely gone. First, we started buying appliances for some functionality, then we started using MSPs for some or all functionality, then some vendors wanted to deliver in a VM where they could make configuration much easier by controlling the environment. That was the first step to virtualizing purchases. Then we started looking at infrastructure-as-a-service (IaaS), then SaaS, then some vendors offered PaaS … Currently, all of the cool vendors are offering containers—which are an improvement over VMs, and offer a virtual appliance that is quick to get running and tested to do what it was purchased for. Or at least tested to do what it was sold for. We’ve all got stories about what we did with these purchases that were “off label”—things that a product really wasn’t designed for. Along the way, we also introduced open source vendors; a bit of an oxymoron that really described service orgs that base their product on an open source project. Some far more successfully than others.
And all of that, dear reader, is why we are here. Before purchasing, there is a lot more to find out than there used to be. What, actually, is the product this software vendor is selling? In the end, IT is looking to solve a problem. Most of the time, whether that problem is solved by SaaS, local install or cloud instance is less important than how well the problem is solved. But implementation—and licensing—are important to an organization if not immediately, then over the long term.
When purchasing an open source “product”, you’re … actually not. You are getting the product and purchasing support. Since open source can be hacked to run just about anywhere given enough time, more than one OSS vendor has pretended that makes them superior to commercial products targeted at a specific platform. That is blatantly untrue—unless the OSS vendor is supporting the product anywhere and everywhere which, of course, they are not. I can port the OSS project MyFunApp to any platform I want without paying for support that won’t do a thing for me when I get it up and running on OS/2 (as an extreme non-existent example).
SaaS has more issues when it comes to TCO. While pay-as-you-grow is cool and all, locking in a monthly payment forever is a big step and should be considered. And at an enterprise, “forever” needs to be considered realistically. Implement a particular SaaS CRM and you are unlikely to move to another, even if you claim that you will in a heartbeat. It’s work. A lot of work. It is definitely possible, but for most organizations, unlikely. So know what you are getting into. And while you are evaluating, don’t forget to consider variable charges, which most SaaS products have. Make certain you understand what the actual monthly costs are likely to be. IaaS suffers this same variability problem, as many of us have learned.
Containers are a very sweet solution to appliance-like functionality—drop a container into your Kubernetes flavor of choice and move along. The problem here is a combination of proliferation—how many are required? One per pod can get expensive over time, for example. Those resources aren’t free, no matter the platform. The other issue is updates. Automatic updates are the norm for container instance-delivered products. From a security perspective, you should have questions. Updating things in your network should probably require your approval.
I’m not suggesting that one delivery method is better than others here; I’m simply suggesting that we all need to be more deliberate about those choices than we’ve needed to be in the past. Knowing not just SLAs but the cost and support implications of every choice is important both today and down the road.
Keep kicking it, and keep picking the solutions that best solve the organization’s problems. Just be aware that sometimes, the issues a delivery method introduces undermine the effectiveness of the solution.
Adhering to the open source definition enables a large, passionate community to collaborate and share their work, insights and innovations on a given OSS project. Companies working in commercial open source add to that value by turning what may look to enterprises like “raw material” into whole product.
These combined efforts serve to improve products, while continuing to protect customers from the stranglehold of proprietary vendors. Beyond just open source, adherence to open specifications (such as CMIS in the content services space) and implementing open RESTful APIs provides a treasure trove to developers that they can quickly and efficiently build upon to add new innovative functionality into the solutions they craft to meet specific business needs.
When vendors employ open thinking at all these levels (open source, open standards, open APIs), there are commercial benefits across the board. The enterprise customer has a hedge against lock-in, can benefit from the innovation across the community, and, perhaps most importantly, can quickly and nimbly respond to changing market conditions while relying on the robust software quality commercial open source provides.
James Dixon, Pentaho Founder and CTO, has described the approach of commercial open source as being akin to a Bee Farm. Bees can, of course, create honey on their own in the wild, but most of us buy honey that comes from a farm. The beekeeper’s job is to create conditions that attract the bees in the first place, and then (bravely!) collect the resulting honey before refining, packaging and distributing in a way that appeals to consumers. This system of open collaboration adds value throughout the supply chain, from the bee to the beekeeper to the customer at the breakfast table.
Likewise, in commercial open source, the vendor takes on the role of beekeeper, creating conditions in a community that attract and retain contributors to help create a better product for all in a win-win-win scenario:
I can’t think of a more perfect metaphor for the role of commercial open source. In fact, as a nod to James’s insight, years ago the Alfresco user community named their organization the “Order of the Bee.” What a complimentary match for our company, which, after all, is named after an open air, outdoors experience!
The open source mindset provides areas of opportunities along the entire supply chain, from creation of software to products and services on which the software runs. Just as bees are integral to honey, open source is integral to today’s digital business environment.
Chris Wiborg is Vice President of Product Marketing at Alfresco Software. In his role, Chris is responsible for setting and executing the go-to-market strategy for Alfresco’s Digital Business Platform. Connect with him on Twitter and Linkedin.