A long-time platform-politics writer, co-founder of Macromedia, and operator of the 'broadband mechanics' blog. In the late 2000s he was one of the most vocal advocates for open social and data standards and a frequent critic of closed PaaS platforms including force.com.

Did force.com really have unique capabilities that justified lock-in?

Yes for its target customer in 2008. Apex (the proprietary language), Visualforce (the proprietary UI framework), the metadata-driven object model and the multi-tenant infrastructure together delivered enterprise CRM customisation at a tempo no LAMP stack could match. The price was that the code did not run anywhere else.

Is the 2008 essay's argument still useful in 2026?

Partially. The 'pick one' framing is still useful for greenfield platform choices. It is less useful for understanding the modern Salesforce stack, where the lock-in is multi-layered: data on force.com, identity on Slack, analytics on Tableau, and agent orchestration on Einstein 1 / Agentforce. Customers now juggle several lock-ins from the same vendor.

What is the modern equivalent of the force.com vs LAMP choice?

In 2026 the closest framing is Salesforce Agentforce vs an open agent stack built on LangChain, LangGraph or Mastra running on Postgres. The trade-off is roughly the same: managed and proprietary versus portable and self-assembled, with the same incentives and the same blind spots.

Lame Platforms or 'Lock In', Pick One

The essay below is a 2026 editorial reconstruction of a post originally published 23 July 2008 on blog.kingsley2.com. The original carried the title “Lame Platforms or ‘Lock In’, Pick One” and was written from inside Salesforce in response to a force.com critique from Marc Canter. The Kingsley 2.0 archive preserves the substance of the original and pairs it with an updated section on how the platform lock-in argument evolved across the Slack acquisition, the Tableau and MuleSoft additions, and the 2024 Agentforce pivot.

The 2008 setup

In the summer of 2008 Marc Canter was one of the most consistent advocates for open data and open platforms on the web. He had been making the case for years, and his critique that month was directed at force.com, the Platform-as-a-Service that Salesforce had launched in 2007 and was actively promoting as a multi-tenant alternative to LAMP-stack enterprise development.

Canter’s complaint was that force.com locked customers in. Code written in Apex (the Salesforce server-side language) did not run on any other platform; UI built in Visualforce did not run on any other platform; the metadata model could not be exported into a non-Salesforce database without rewriting the schema. The whole thing was a one-way door.

The author of the 2008 essay, then a Salesforce employee, did not contest the description. He contested the framing. His argument was that any platform that is uniquely good at something will, by definition, lock you in. The portability you give up is exactly the cost of the capabilities you get. The choice is not “lock-in versus no lock-in” but “lock-in versus lameness”.

He extended the argument to the closed platforms of the day: the iPhone (in its first year as a developer platform, after the App Store launched in July 2008), Facebook (whose platform had launched in 2007), and Google App Engine (which had launched in April 2008). Each of them offered unique capabilities and each of them locked developers in.

The proposed compromise was the one that survived: platform vendors should expose generalised functionality through standardised protocols (web services APIs, OAuth, REST) and reserve the proprietary surface for the specialised, high-value parts. This is approximately the architecture that won.

What the essay got right

Three of the four predictions held up cleanly.

Closed platforms won on capability. force.com, the iPhone App Store, the Facebook Platform and the various App Engines (Google, Heroku, later AWS Amplify and Vercel) all retained substantial closed surfaces, and in every case the closed surface was where the value lived. LAMP-only enterprise development remained possible but stopped being competitive for the categories the closed platforms had carved out.

Web services APIs became the safety valve. The compromise the essay proposed (standardised access to generalised functionality, proprietary access to specialised functionality) is the architecture every major closed platform of the 2010s adopted. Salesforce’s web services API, the iPhone’s MFi and HomeKit interfaces, Facebook’s Graph API, Google’s App Engine APIs are all variations on the same pattern.

Vigilance against portability remained a geek virtue but not a practical strategy. The author wrote that “vigilance against portability issues is definitely a laudable geek virtue” but framed it as a virtue that competed with innovation. By the late 2010s the open-source equivalents of every closed platform existed (Apex equivalents on Postgres, iOS equivalents on Web), and the equivalents were objectively portable, but they were not what enterprise customers bought.

What the essay missed

The fourth thing the essay missed was the consolidation of lock-ins inside a single vendor’s portfolio.

When the essay was written, Salesforce sold one product (Sales Cloud) on one platform (force.com), with a small adjacent app store (AppExchange). The lock-in was clear, single-axis, and visible to the buyer.

By 2026, the buyer who chose Salesforce is locked into:

force.com / Hyperforce for application and data
Slack for messaging, channels and the workflow surface
Tableau for analytics
MuleSoft for integration
Einstein 1 / Data Cloud for the unified data lake
Agentforce for the agent layer

Each piece was acquired or built. Each has its own pricing, its own metadata model, its own SDKs. The 2008 essay’s framing (“pick one”) assumed that the customer was choosing between platform vendors. The 2026 reality is that the customer chooses one vendor and is then asked to choose between that vendor’s six lock-ins.

The author’s argument that lock-in is the price of innovation still holds for any single one of those products. It does not address the question that 2026 enterprise architects actually ask, which is how to navigate the inter-product gravitational pull when each of the six wants to be the system of record.

The AppExchange story the essay anticipated

There is one prediction the essay implies but does not state, which is that platform-native app marketplaces would become economically central. AppExchange existed in 2008 but was small. The essay treated it as evidence of force.com’s uniqueness without quite saying so.

By 2026 AppExchange has approximately 7,000 listings, hosts an entire ecosystem of independent software vendors that build only for force.com, and generates measurable indirect revenue for Salesforce through certified-consultant flows. The same pattern played out on the iPhone App Store (with a different revenue model), Shopify (with the Apps Plus partner programme), and Atlassian Marketplace.

The 2008 essay is one of the small pieces of evidence that this pattern was visible from inside the platform vendors before it was visible from outside. The author was not the first to see it, but he was earlier than most.

How to read this essay in 2026

The 2008 framework is still useful if you read it narrowly: when choosing a single platform, you trade portability for capability, and the trade is honest. The framework breaks if you try to extend it to a 2026 portfolio choice, because the portfolios contain internal lock-ins that the 2008 author had no language for.

The contemporary equivalent of the choice the essay described is between Salesforce Agentforce and an open agent stack built on LangChain, LangGraph or Mastra running on Postgres. The shape of the trade-off is unchanged. The new wrinkle is that the closed side is now built on top of six previous lock-ins rather than one, and the customer who picks Agentforce inherits all of them.

The 2008 essay would have approved of the trade. It would have asked, fairly, whether the customer knew what they were buying.

For the same author’s view on social monitoring inside Salesforce, read Walking the Line Between Listening and Stalking. For more on the platform debate of the period, see the Salesforce topic and the SaaS topic, or browse the archive index for the full 2003-2012 era.

FAQ

Who was Marc Canter?: A long-time platform-politics writer, co-founder of Macromedia, and operator of the 'broadband mechanics' blog. In the late 2000s he was one of the most vocal advocates for open social and data standards and a frequent critic of closed PaaS platforms including force.com.
Did force.com really have unique capabilities that justified lock-in?: Yes for its target customer in 2008. Apex (the proprietary language), Visualforce (the proprietary UI framework), the metadata-driven object model and the multi-tenant infrastructure together delivered enterprise CRM customisation at a tempo no LAMP stack could match. The price was that the code did not run anywhere else.
Is the 2008 essay's argument still useful in 2026?: Partially. The 'pick one' framing is still useful for greenfield platform choices. It is less useful for understanding the modern Salesforce stack, where the lock-in is multi-layered: data on force.com, identity on Slack, analytics on Tableau, and agent orchestration on Einstein 1 / Agentforce. Customers now juggle several lock-ins from the same vendor.
What is the modern equivalent of the force.com vs LAMP choice?: In 2026 the closest framing is Salesforce Agentforce vs an open agent stack built on LangChain, LangGraph or Mastra running on Postgres. The trade-off is roughly the same: managed and proprietary versus portable and self-assembled, with the same incentives and the same blind spots.