[Helma-user] Proposal for future Helma project organization

[Michael Platzer]

Hannes Wallnoefer schrieb:
> back in summer, Orf on hosted a one-day retreat to discuss and invent
> the future of Helma. The main idea is of course to provide some
> structure, allow more people to take responsability, take off weight
> from my shoulders, etc.
>
> Of course, things took more time than anticipated, but I'm happy to
> announce that I finally finished my proposal that should give us some
> formal rules and structure.
>
> http://dev.helma.org/Wiki/Helma+Project+Bylaws/
>
> I personally think it hits a sweet spot between rules and freedom, but
> then, I'm the one who wrote it. Please let me know what you think
> about it, where it is too  much, what is missing etc.
>   
Hi Hannes, hi List!

Finally I found some time to response to your draft of the 'Helma 
Project Bylaws'.

Couple of thoughts and questions came up while reading through it. I 
will list them here in the following.

== definitions / scope ==

* I assume this document does not just deal with the Helma Web 
Application Server, but with all related software projects under the 
hood of the Helma label? Is this assumption correct? If yes, then which 
are currently these (active) projects/modules?
* The 'Helma Project Goals' state the creation of a software development 
environment, as well as the creation of software itself (accompanied 
with some generally desirable attributes). To say the least, this is 
quite a broad scope. Maybe this isn't the primer intention of the 
document, but providing a focus really helps a lot in communication and 
helps outsiders while approaching Helma. We also shouldn't be afraid of 
referring to Helma as a *web* development environment. Yes, Helma is 
capable of being the foundation of all kind of software, but its clear 
strength is in web development.
* As with any project a glossary (for the website, as well as for this 
document) would clarify couple of things. Suggested terms: Helma Group, 
Helma Project, Helma, Helma 2, helmaLib, modules, Gobi,.. The term 
'module' for example is used throughout the document, but it is unclear 
of what the authors consider to be a module. Are modules just extra 
libraries, such as the helmaLib, or do we consider all kind of separable 
'aspects' (such as rendering, db-mapping, logging, scheduling, testing, 
security,..) as single modules? Is the maintainance of the website and 
the repositories for example also a 'module'?

== framework ==

Helma (the java core, as well as the bundled modules) provides little 
framework of how to write your web application, if you compare it to 
other frameworks like Ruby on Rails. A freedom, which is by the way, 
much appreciated if you have gained enough experience with web 
development, but forces newbies to deal with all kind of aspects of 
clean web coding, that they are not even aware of.

Knallgrau (and i guess that other helmatics do the same) is 
progressively developing its own library ('knallgrauLib'), a framework 
which is used throughout our projects. Something that is inevitable 
anyways, in order to make programming in teams more efficient. The 
knallgrauLib is of course perfectly fitted for our very own 
knallgrau-purposes. I talked to you (Hannes) about a common, more 
powerful helmaLib (a merge of a knallgrauLib, orfLib, system1Lib, 
whatevaLib) a while ago. But being realistic, this is not going to 
happen anytime soon. Each stakeholder has its own application stack to 
maintain and to build on, and frankly no one will be willed to refactor 
their applications just for the sake of creating a common denominator. 
On the other hand, these libraries can be highly useful for others. 
Therefore I see such libraries/frameworks also as Helma modules, being 
distributed together with Helma, even if they try to solve similar issues.

Having said that, I will use this posting for publishing the status quo 
of our knallgrauLib, so that you can get a feeling for what i am talking 
about:
-> http://michi.knallgrau.at/knallgrauLib (not an official, supported 
version; just the current status quo without much documentation)
The knallgrauLib tries to solve the following concerns: Pagination, 
Internationalization, Form Rendering, Form Validation, Security, Ajax 
Helpers, Hooking-Mechanism ('Events'), Timing, ImageMagick-Wrapper,...

I would love to see the knallgrauLib become accepted as a Helma module 
under the terms of the 'Helma Project Bylaws' §2.1 (quote: "A maintainer 
should keep some balance between his or her internal work and 
communicating the work with others inside and outside the module."), and 
would love to see other people using it. Still, dont expect too much of 
such a module. Ressources are, as always, tight and the next client's 
deadline unfortunately always of higher priority.

== decision making process ==

Part of the criticism about Helma is the lack of speed, when it comes to 
decision making. Yes, having single module maintainers will certainly 
help. But whenever a decision of one module affects another module, we 
might experience a stall in that process. Especially when considering 
the number of egos (including myself) in the community. So, on the one 
hand, we must try to limit the number of module-overlapping issues (i.e. 
dependencies) when defining modules, and on the other hand, we still 
need a fast agile decision (by a single person? by the committee??) in 
order to prevent dead-locks.

Two examples for ever-lasting issues:
1) The rendering engine. Lots of different thoughts have already been 
shared regarding this issue, and we still seem to be far away from a 
*common* sense of how the future rendering should look a like. But then 
Juerg Lehni showed (with the imho most impressive contribution to Helma) 
that providing a templating engine does not need to be baked into Helma, 
but can be provided with some funky javascript-code (or by using some 
well-known java implementations). Subsequently you (hannes) provided 
some java code for helma 2 to make such implementations easier in the 
future. Perfect, issue resolved! The reason, why it still seems to be an 
unsolved issue, is that juerg's rendering engine never became part of 
the helma distribution. And people wonder, whether this extension is an 
'officialy supported' enhancement of helma. So, despite having module 
maintainers, a strong but agile (sorry for using this ugly buzzword 
twice) distribution maintainer will be much needed.
2) The re-design of the website. I dont want to dig through the mailing 
lists, but this issue is probably about as old as the discussion about 
the templating engine. Markus volunteered for taking this issue into his 
hands, provided several different design drafts, provided some adapted 
designs, waited for months, asked for input whether he should do another 
re-design, and now, after no one ever felt like making a final decision 
on this issue, Chris went along and put up a totally different version 
up, which hardly meets any of the initial goals (sorry for the blunt 
criticism, chris). We could have had a new website a long time ago, and 
by now could have already seen a redesign of the redesign. This issue is 
just a perfect example, that making no decision is the worst decision at 
all.

Both issues indicate that we've seen some very very slow process in the 
past. But i think, the 'Helma Project Bylaws' show a way out of this 
dilemma. And the longer i write this email, the more i can see how it 
will actually improve things. Still, I wanted to point out that simply 
splitting responsibilities into 'modules' won't make the deal. The 
single, strong entity (person/committee), that brings the pieces 
together again, will still be much needed.

So, to sum it up: +1 for the draft.
looking forward to get things going,

  michi / knallgrau