Hi Matthew,

Thanks for posting about this. I’d like to offer some further insight here, as we’re not moving away from open source as much as the market is evolving. Our observations of the industry is that the world is becoming more mixed. Most customers have heterogeneous environments, ultimately they care most about whether solutions work for them and can be trusted. Being open has advantages but isn’t the #1 deciding factor for a purchase. Meanwhile, even most successful open source companies are succeeding with “dual license” models with commercial versions of product, and proprietary companies are embedding more and more open source.

Given this, we believe the problem we’re solving is equally applicable to both open and closed source ISVs, and everybody in between. All need to test, deliver and maintain products in ways that engender trust with their end customers. Our Solutions Factory does this in a code-agnostic way, i.e. we don’t need access to source code. That being said, I believe that open source ISVs will greatly benefit, perhaps more than closed-source, because the diversity of components that can appear in their stacks.

Finally, Spike will continue to have a lot of open source DNA. The Solutions Factory includes a lot of open source, and we “give back” several components such as our testing tools, and also interoperability toolkits (look for Open Solutions Alliance branded components on Sourceforge). We’ll do more of this in the future, and continue a healthy symbiotic relationship with the Community.

Dominic

I’d also like to comment regarding:

> its original vision of providing support and services for pre-configured
> open source stacks did not live up to expectations.

IMO this is true when one emphasized *pre-configured*. We’ve learned, and I suspect Sourcelabs did too, that a one-size-fits-all stack is not what the market demands. The market demands support and services for OSS components, but they want it with the components *they* decide to use, depending on the requirements of the applications in question. The real problem is that of mass-customization, being able to provision, assemble, test, package, deliver and maintain custom stacks based on a broad library of components. The Solutions Factory does this.

Dominic

“The real problem is that of mass-customization, being able to provision, assemble, test, package, deliver and maintain custom stacks based on a broad library of components”

Close, but no cookie. Mass-customization is not a problem to be solved, it is one of several tools that you need to solve the real problem. You get the cookie if you find out what the problem is (without spending another 50M USD and brownie points if you figure out the other tools.

[...] other news about betrayal or poor principles, Watch this take on SpikeSource. Intel’s investment in SpikeSource goes beyond financial ties, however. It has also picked the [...]