Why we develop Stubbles

Long Version:

Release cycles and maintenance requirements
In our company 1&1, the world's largest web hoster and number two in the german DSL market, we are responsible for highly marketing driven websites which require sometimes drastic changes from one day to another. This means we have to implement new features very fast and use them instantly. Often this also requires changes in our basic infrastructure and extensions (not changes!) to existing APIs. If we would use another framework we would be highly dependent on their release cycles which in the end means we must maintain our own version of it to be able to use the latest features. But if we do so we can just maintain our own framework, this yields in the same amount of required resources.

Why "use your force to improve another framework" is not a valid point
Some people said that we would better use our forces to improve existing solutions. The key point which renders this argument useless is that there where frameworks, components and applications even before the Zend Framework or Solar or the ez Components were started (pat, XP-Framework, PEAR, just to name a few). So why did the people starting those frameworks not stick to existing components and improved them? When they did not - and I assume they had good reasons for not doing so - why should we?

Even if we would have used another framework our natural choice would have been the XP-Framework, developed at 1&1 since five years and not only enterprise ready to name a buzzword, but enterprise approved™ in a bunch of applications. Therefore the question is not "improve [Zend|Solar|ez] or create something new" rather than "use and improve XP or create something new" - which at last is a decision we have to defend within the company, not the public open source scene.

Do we really reinvent the wheel?
We would never even think of creating a new Phing, a new unittest framework or blog software. We have a pressing need to build marketing driven websites; capable of variants and variant tests; with a lot of logging which has to suit internal rules of how logfiles need to look like; using our approved design patterns; with high flexibility in configuration; giving our website producers the tools they need to achieve the results that other departments expect from them. As far as we can see and overlook the existing solutions nothing comparable exists.

More company influence
One of our key points for Stubbles is the existence of a Java framework used in our company for several years now. Our producers know its syntax and how to work with it to build websites. But the framework has drawbacks, one of them is the time required to implement new requirements, mainly due to its Java nature. Stubbles will resemble some parts of this framework that will allow our producers to work in Stubbles just like they are used to in the Java framework. That urges us to decisions like the naming of XSL tags which we simply do not want and more important can not discuss with other developers from outside the company if we would do this development in an external framework.

To open source or to not open source
We could have made the decision to not release parts of our work as open source. This would have saved us a lot of time for debates and for maintaining the public parts. However, we use a lot of open source software in our company, not just in our department. A lot of our applications is driven by open source software. By releasing some parts of our work we give something back to the open source community. Maybe nobody beside us will ever use Stubbles, we do not expect that Stubbles will ever be used by a wide range of people. But maybe someone takes our ideas as inspirations for improvements in his own software. With Stubbles we take part in the public competition of ideas. It is a great way of communicating our thoughts about PHP itself, development in PHP, software architecture and PHP-related stuff and getting feedback which in turn can be used by us to improve our solutions.

Final note
One of the points mentioned is not valid in your eyes? It is in ours - which is sufficient enough.