This is statement regarding my tweet:
Still don't get that #TYPO3 Surf Hype. It's a NIH product and resembles everything we try to avoid in the community recently.
People started asking me about what I use instead, what NIH means and why exactly the problem with TYPO3.Surf is. As twitter only allows 140 chars, I decided to shortly write down this gist.
NIH means Not Invented Here and describes ignoring existing knowledge or solutions in favor of inventing something yourself. So, you are faced with the problem that you are missing a good deployment software, ignore existing ones and start creating a new one.
In this case, the guys that invented TYPO3.Surf wanted to have a deployment software written in PHP, which at that time (2011), actually didn't exist. So, this software wasn't 100% NIH-software in the beginning but meanwhile it just is. But there was Capistrano for example, a deployment software for the Ruby world, that existed at least since 2006 and looking at the syntax of TYPO3.Surf, you know that Capistrano is the origin of all the ideas and concepts.
And still, I am ok, with using a good software in language A and port it to langauge B, if language B is missing such a solution completely. But, the TYPO3.Surf guys did some huge mistakes.
If you want to create a solution for the PHP world, you don't call it TYPO3.Surf. TYPO3 indicates, that the solution only works for TYPO3 and Surf does not tell you anything at all. It's a super cool non-descriptive term that you can use on conferences but it will never be found on google if you search for PHP deployment.
In the beginning TYPO3.Surf was a package for TYPO3.Flow, thus you could only deploy TYPO3.Flow with it. Fortunately this changed and you can deploy whatever you want with it, unfortunately that standalone version was simply too late to be an option for the whole PHP world.
Actually I do use Capistrano but a single product name does not matter here. I rely on a product that has proven to be stable for years and that's the reason I still use it, even if there are more fancy solutions out there. Deployment software is not just something you reinvent or which you want to allow to fail occasionally. You want to have a fast and reliable tool, that updates the live version of your website with the least impact for the user. How can one even think, that this is easy to reinvent and maintain?
Whatever, I do not say TYPO3.Surf is bad software, I just don't trust it to be stable and reliable enough. And even though Helmut Hummel is maintainer of that software – and I know of his knowledge and experience –, with just that little manpower I rather use something else.
Quite simple. There was a time when TYPO3 guys thought, they could change the world, told everyone and then failed. Back then, out of nothing a very small group of people claimed they knew better, just by announcing to write a new framework, a new template engine, a new CMS and a new deployment tool. If that isn't hybris, what else is?
So far, two of these 4 products failed. Please do not get me wrong. This is no bashing, reality just shows, that the adoption rate of Flow and Neos is very very low. TYPO3.Fluid has the chance to actually have an impact on the PHP world, now, that it is standalone as well and with a lot of poeple using and maintaining it. Honestly I do expect TYPO3.Surf to follow Flow and Neos here. Again, it's not bad software, it's just not needed.
If you look at how much PHP matured during the last 4 years (PHP7, Composer, PSR), you get an impression of what is changing in the PHP world right now. People are focusing more and more on (PHP) community driven solutions, that are stable, reliable and well maintained. Today, you need a lot more than a good idea and an announcement to be heard in the PHP world. So, rather participate in solutions, that are adopted and driven by many skilled people and show the PHP world that TYPO3 has quite a lot of these (people) by contributing to non-TYPO3-specific solutions.
The problem, riding a dead horse, is not riding a horse, but a dead one.
You guys are free to do whatever you want but I do recommend to not use TYPO3.Surf. Especially not, if you are a trusted developer in a company, deciding not just for you, but a whole team. Evaluate and choose wisely.
And if you still consider riding a dead horse, maybe these strategies might help:
-
Buying a stronger whip.
-
Changing riders.
-
Threatening the horse with termination.
-
Appointing a committee to study the horse.
-
Visiting other sites to see how others ride dead horses.
-
Lowering the standards so that dead horses can be included.
-
Re-classifying the dead horse as “living, impaired”.
-
Hiring outside contractors to ride the dead horse.
-
Harnessing several dead horses together to increase the speed.
-
Attempting to mount multiple dead horses in hopes that one of them will spring to life.
-
Providing additional funding and/or training to increase the dead horse’s performance.
-
Doing a productivity study to see if lighter riders would improve the dead horse’s performance.
-
Declaring that as the dead horse does not have to be fed, it is less costly, carries lower overhead, and therefore contributes substantially more to the bottom line of the economy than do some other horses.
-
Re-writing the expected performance requirements for all horses.
-
Promoting the dead horse to a supervisory position.
Origin: https://kenhomer.wordpress.com/2008/11/12/riding-a-dead-horse-the-wisdom-of-the-dakota-indians/
Besides the whole shit storm, would you mind to share a few more details on how you do TYPO3 deployments with capistrano?