[TYPO3-project-seminars] Seminar Manager 0.6.1 performance problems

[Oliver Klee]

Hi Peter, hi Tomas,

thanks for your thoughts.

Maybe there are some misconceptions concerning how our development is 
organized. I'll give it a try to make a few things clear.

Peter Holik schrieb:
>> he meant something like, that a program which is coded well is 
>> automatically fast and that he doesn't want to pay for cleaning your 
>> bad code...

> Which I find quite obvious too.
> It is one thing to (agressively) ask for sponsorship for new features.
> But to ask for money to clean your own code (bugs)? That's greed.

If I understand you correctly, you assume that

a) the Seminar Manager code is bad or not clean
b) clean code automatically is fast
c) improving code is work that should not be paid
d) getting paid for extension development is greed

(Please correct me if I have misunderstood you or misinterpreted your 
words.)

Concerning b), that is not always the case. Code that is clean is not 
automatically fast, but just is more readable and easier to change 
(which includes performance optimization, too)

Performance optimization is a task that takes quite some time:
- analyzing the code
- finding bottlenecks
- analyzing which changes actually improve performance
- making sure that the changes don't break anything (e.g. by adding unit 
tests for parts of the code that aren't already covered by unit tests)

This we either could do in our spare time or in our work time (which 
means that someone needs to pay for it). (Some of the work we actually 
do in our spare time because it's a kind of work that's also fun, and we 
decide for ourselves which work we do just for the fun of it.)

With this extension, you can download tens of thousands of Euros worth 
of development which was financed by other customers.

This is a very important point: You don't pay for downloading the 
extension, and we don't guarantee that this extension will cover all 
your needs.

When this extensions has shortcomings (which it certainly has), you have 
quite a few options:

- You can decide that this shortcoming is not important enough for you 
to do anything about it.
- You can decide that it would be nice for you if this got changed, but 
it isn't important. Then you can enter a bug in a bug tracker to make us 
aware of the problem.
- You can decide that you needs this changed and provide some code 
(which needs to live up to our quality standards so that we will 
integrate it).
- You decide that this needs to be changed and sponsor these changes.
- You decide that this needs to be changed, but you don't would like to 
spend money for this. Then you need to wait until either some other 
customer invests time or money in this, or we until like to do this in 
our spare time.
- You don't generally need new features, but you would like to have any 
bugs which you encounter to get fixed. That's why we offer support 
contracts ("bug-fix flatrates").

I hope I have been able to clear up a few points.

Best regards,


Oliver