We were unable to load Disqus. If you are a moderator please see our troubleshooting guide.
I don't think this post really refutes Sinclair's main point, which, as Andy points out in overly disparaging terms, he clarified today to indicate forking essentially into multiple distros. And in that context, he's right.
Why is forking bad for the enterprise?
If the company wants to build their own PaaS to meet their exact requirements and wants to own their cloud application infrastructure, forking off an existing base is a great way to benefit from hard work and lessons learned by others; code reuse writ large. I totally agree with Stephen that the combination of distributed version control and permissive licenses make that a very viable option for developers and companies alike. But most enterprises aren't looking to own their infrastructure at that level.
In the case of PaaS they're looking for an adoptable (and adaptable) platform where they can host their applications and receive as much organizational value as possible. The true requirements rarely (if ever) dictate whether the platform is open-source code or proprietary code. (and when they do, it's a political statement more than anything else). From a cost of operations and maintenance perspective, most companies will look to purchase a platform to run their cloud applications. That's not a surprise to anyone, I hope.
For this reason (and others like ignoring embedded flavors), the relevant scope of Linux distributions is fewer than 10 rather than hundreds, which limits the strength of the forking argument in this scope.
When making a purchase decision, prudent buyers are rightly going to consider the lock-in/value trade-off (http://www.cloudave.com/264.... An "open" ecosystem and "core compatibility" can seem appealing in that sense.
But that's where the insidious danger of forking lies.
While it's definitely true that any CloudFoundry offering that is Core Compatible will support the same basic set of capabilities - and any application that limits itself to those capabilities should be able to be migrated, history has shown us that developers tend not to constrain themselves to the core capabilities when faced with a challenge.
I'm sure many of us have had to try to migrate JEE applications from WebSphere to WebLogic or vice versa. How many of those transitions were as seamless as the existene of a "standard" would have you believe?
The problem with forks is never with the core. It's with the changes. And while each change is presumably beneficial, adopting them limits the portability of the applications.
If you map forked distros in a family tree (as in the diagram linked by Patrick Chanezon in the main post), once you pick a starting point on the tree, you can only move further down the branch, because you're likely relying on features that only live on that branch. And every time you either select a platform, or decide to leverage a new capability, you're restricting your choices even further.
Now, there are many reasons for a buyer to consciously make a decision to limit the scope of their future options. It's a similar calculus to deciding to use closed-source software. If the value is greater than the cost, it's a smart move.
Clearly there's the possibility of good to come from forking, but there seems to be a distinct lack of acknowledgement that the choice to fork reduces real-life compatibility (as opposed to marketing compatibility) and that open-source is not a free lunch.
Disclaimer: Until January, I was Lead Architect for Customer Solutions at Apprenda, so my views do come tinted with Apprenda-colored glasses. But they've also been shaped by my experiences talking to customers searching for a PaaS and numerous application migrations between JEE servers.
It might be worth mentioning the ongoing compatibility program "Cloud Foundry Core" in place to ensure application portability/compatibility across hosted providers of Cloud Foundry. Don't forget that 'time' based incompatibilities can also exist in any OSS project with newer versions vs. old also raising a classic compatibility problem. Cloud Foundry Core tries to help users with both:
Thanks for this post, Stephen.
I'd point out that in terms of the original blog entry, Sinclair's laughable highlighting of the "fork me on Github" banner *of the Cloud Foundry DOCUMENTATION* was the lightning rod, demonstrating a fundamental lack of understanding of how forking works today, specifically w.r.t. Github and contributions. That's why the "minor spat" broke out on Twitter, fundamentally. His updated post today - which tumbleweeds roll past as oxygen drains from the desert - attempts to rewrite history, rather than admitting that he used a terrible analogy in the first place. Oh, and I'd mention that it wasn't just me that called Apprenda out, but more than one of our Cloud Foundry partners joined me (obvious disclaimer here - I'm developer advocate for the CF platform, so take my views with any pinches of sugar or salt you prefer).
I'm not at a level in the project where I can make policy pronouncements, but I do have a very strong engagement in the community. I'll make a few remarks.
1. Cloud Foundry Core is an attempt to ensure that we do, as a community of Cloud Foundry users and vendors, stay together from an API compatibility perspective.
2. The vendors and partners I interact with daily are big fans of what we're building and keen to understand how to retain that compatibility, no matter the FUD from our friends from rival platforms. I have great relationships with those vendors, partners, and implementers, and I'm happy to help them stay in lockstep with progress as appropriate.
3. The past month or two has seen a change in approach from the CF engineering team, and that will be evident to anyone following the relevant (public) mailing lists via Google Groups, the source code on Github, etc. It's not just our outward approach - I'm personally feeling more connected to the engineering and product groups myself, than ever! We tried a Gerrit approach over the past ~10 months, and we're moving to something more open right now. It's adaptation, and I personally believe it is for the benefit of both the CF project, and the surrounding community.
4. I completely get the issues raised around OSS licensing, permissiveness etc. I loved Luis Villa's post on this a month or so back http://tieguy.org/blog/2013... - you know me - I've been a decade in IBM, and longer than that as part of OSS communities. I've worked with big businesses. I get it. Times change, and we as a (closed)|(open)|(inclusive)|(software) community need to adapt.
My 48.3c. Enjoy.