Skip to content

Instantly share code, notes, and snippets.

@alexanderschnitzler
Created December 18, 2016 10:21
Show Gist options
  • Save alexanderschnitzler/fe6d26087e3f02a8718734bcb639c64a to your computer and use it in GitHub Desktop.
Save alexanderschnitzler/fe6d26087e3f02a8718734bcb639c64a to your computer and use it in GitHub Desktop.
TYPO3.Surf

TYPO3.Surf

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.

What is NIH and why does it harm?

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.

The product name

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.

It needed TYPO3.Flow to work

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.

What do I use instead?

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.

What is the overall problem of the TYPO3 world, that TYPO3.Surf stands for?

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.

Résumé

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:

  1. Buying a stronger whip.

  2. Changing riders.

  3. Threatening the horse with termination.

  4. Appointing a committee to study the horse.

  5. Visiting other sites to see how others ride dead horses.

  6. Lowering the standards so that dead horses can be included.

  7. Re-classifying the dead horse as “living, impaired”.

  8. Hiring outside contractors to ride the dead horse.

  9. Harnessing several dead horses together to increase the speed.

  10. Attempting to mount multiple dead horses in hopes that one of them will spring to life.

  11. Providing additional funding and/or training to increase the dead horse’s performance.

  12. Doing a productivity study to see if lighter riders would improve the dead horse’s performance.

  13. 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.

  14. Re-writing the expected performance requirements for all horses.

  15. 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/

@IchHabRecht
Copy link

So, this software wasn't 100% NIH-software

Why are you calling it NIH-software when you admit there wasn't any other tool out there? What is 10% or 50% NIH-software?

but meanwhile it just is

How can a software become a NIH-software afterwards?

But there was Capistrano for example, a deployment software for the Ruby world

So you want people to use a tool where they a) don't understand the programming language b) doesn't solve their current problem (deploying TYPO3)?
And isn't Capistrano itself a NIH-software?

don't call it TYPO3.Surf

This just says it's coming from the TYPO3 world - but the name doesn't claim any use case.

It needed TYPO3.Flow to work

Why are you speaking about the past here? The tool itself was meant for one purpose. It fulfilled this purpose. Later it was enhanced to handle TYPO3 as well but never meant to solve any (PHP) community problem IMHO.

or which you want to allow to fail occasionally

Is this just an assertion or did you ever had problems with Surf? Have you ever used Surf? How can you tell anything about its stability?

Whatever, I do not say TYPO3.Surf is bad software, I just don't trust it to be stable and reliable enough

Any arguments for your "feeling"?

And even though Helmut Hummel is maintainer of that software

How comes you're claiming Helmut to be the maintainer? The repository belongs to an organization. Last commits show there are many more contributers.

So far, two of these 4 products failed

Where are your arguments for that? Why have Flow and Neos failed?

TYPO3.Fluid has the chance to actually have an impact on the PHP world

But isn't fluid a real NIH-software? Still it has TYPO3 in its name. Why should it succeed then?

with a lot of people using and maintaining

Surf currently has 32 contributors and 373 commits while Fluid has 1192 commits and 44 contributers. I wouldn't say one has more people maintaing it than the other.

Honestly I do expect TYPO3.Surf to follow Flow and Neos here.

Again where are your arguments for your personal meaning?

Again, it's not bad software, it's just not needed.

It is not needed for you. I guess you can't tell anything about the needs of other people.

Especially not, if you are a trusted developer in a company, deciding not just for you, but a whole team

This sentence together with your 15 points long list afterwards makes a fool out of everybody who decides/decided using Surf. Sorry to say this but the "dead horse" is an assertion that isn't based on any argument in your post. As stated above your post only has one single goal: rant about a piece of software you maybe used once (to be honest I even doubt that). But for sure you haven't had any look into the current process.

I don't want to force anyone to use Surf but I don't want to fool on me or anyone else because of using it.

@alexanderschnitzler
Copy link
Author

Why are you calling it NIH-software when you admit there wasn't any other tool out there? What is 10% or 50% NIH-software?

Quite simple. In the beginning, in about 2011, Surf was one of the first deployment tools built in php, but just made to deploy Flow, not websites in general. You can be the first two write a tool in a language but if it's not for the masses, you realize that and then try to compete with other available (PHP) deployment tools, that by then have a far bigger usebase, the term NIH applies again.

Why are you speaking about the past here? The tool itself was meant for one purpose. It fulfilled this purpose. Later it was enhanced to handle TYPO3 as well but never meant to solve any (PHP) community problem IMHO.

That's exactly my criticism. Instead of joining others of the PHP community and building one tool for everybody, a tool from TYPO3 guys, just for TYPO3 guys has been built. This gives others the impression, that TYPO3 guys are ignorant and do not want to share their knowledge with others. Or only then, if the software, written by TYPO3 guys is accepted elsewhere. Fact is, Surf is used in the TYPO3 environment. So, it will be hard to find more adopters and maintainers outside the TYPO3 world, because there are other solutions that are more generic and are found more easily on the web.

Is this just an assertion or did you ever had problems with Surf? Have you ever used Surf? How can you tell anything about its stability?

Yes, I have used Surf, back then when a full Flow was needed to run that tool. No, I didn't experience any major issues with it. But that's not the issue. I say, that if you want a reliable software, look where the maintainers are. You do not build a tool once and it's finished. Thus, you change the codebase, refactor and it's more easy to break your software with fewer maintainers and less time.

How comes you're claiming Helmut to be the maintainer? The repository belongs to an organization. Last commits show there are many more contributers.

Why is it actually relevant who the maintainer is? Looking at the contributors graph at github, you get the impression that Helmut is the only maintainer. So?

Where are your arguments for that? Why have Flow and Neos failed?

Compared to the promises made to not only the TYPO3 world but also the whole PHP world and their adoption rates, I consider these products failed. While Flow has been developed for years, Taylor Otwell created laravel, (btw, I also call that NIH software), but it is incredibly successful. To me, it's proof that people do not need the concepts of the Java world rewritten in PHP to run a web service. Rather does the majority use existing frameworks like symfony or a newcomer like laravel. Looking at Neos I see even less market share. It was meant to be the successor of TYPO3 and a CMS for the masses, to this day it isn't. You can see that differently if you want.

But isn't fluid a real NIH-software? Still it has TYPO3 in its name. Why should it succeed then?

Sure. Fluid is NIH software, like the others. That's what I wrote. And the same applies to Fluid like to Surf. The name indicates, that the template engine is made for TYPO3 and until there was no standalone version, it had the same flaws like Surf, perception-wise. Still, the TYPO3 community needs a lot of marketing to show the world that Fluid can also be used elsewhere and what its benefits are. I just see more people engaging in Fluid than in Surf. That's why I give Fluid a chance to have an impact someday.

It is not needed for you. I guess you can't tell anything about the needs of other people.

If you are so sure about that, than spread the word and show the PHP world, why they should use Surf in favor of something else. It's not up to me to prove, that Surf can succeed. It's a personal statement and noone needs to follow me on this one. If you are happy with Surf, fine. If you want to use and maintain it, fine. Never said, that people should stop using it.

This sentence together with your 15 points long list afterwards makes a fool out of everybody who decides/decided using Surf. Sorry to say this but the "dead horse" is an assertion that isn't based on any argument in your post. As stated above your post only has one single goal: rant about a piece of software you maybe used once (to be honest I even doubt that). But for sure you haven't had any look into the current process.

Here, the problems begin. For whatever reason, you take that personally but calling software a dead horse is something else than calling people names. If you make that up in your head and start accusations, you play a very nasty game. Because harm or offense can be interpreted into everything, then. So, people can no longer criticize software. By dragging this whole thing on a personal level, you are a threat to an open discourse about (software-)problems.

To make that perfectly clear: I even call TemplaVoila a dead horse and by that I do not blame my clients paying me to help them move that horse a little forward. But I do so with the hint, that this way of moving forward cannot be called »riding« any more.

@smichaelsen
Copy link

smichaelsen commented Dec 19, 2016

Besides the whole shit storm, would you mind to share a few more details on how you do TYPO3 deployments with capistrano?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment