[Helma-user] Proposal for future Helma project organization

[Robert Gaggl]

hi everybody,

First i'd like to state that i really appreciate hannes' proposal, as 
it's a first important step towards a clearer structure of the helma 
project itself and the further development. So i'm all +1 for it.

I think it will need careful consideration which parts will be a 
"module" in the sense of a separately maintained subproject. For the 
development part of helma at the beginning i can imagine only two of 
them: helma core and  javascript-lib(s). Both modules will possibly be 
divided into different modules in the future [1]. But the development is 
just one part in the project, besides documentation/training, release 
management and communication/presentation (including website 
maintenance), which i personally consider of equal importance.

Reg. the maintainers: Imho first and most important the maintainer of a 
module (esp. in the development area) must lead the process of 
identifying targets that need to be addressed by the module. This for 
sure is a quite difficult task in its own, since it basically means to 
figure out which issues are of importance for current and future helma 
users - and there are a lot of different points of view around. Having 
this task accomplished the call for contributions and the 
evaluation/discussion of them must follow (next challenge). The role of 
the maintainer here is not to solve the issues on her own, but to guide 
the process towards a solution that is best and everybody (or at least 
the majority) can agree with.

Imo a maintainer of a helma module shouldn't first run on her own (by 
eg. committing a bunch of own code) and then ask for discussion of and 
contributions to this base (been there, done that ;). This means giving 
the development process a direction that matches the maintainer's (or 
her company's) needs, but that's not what i'd like to see the focus on 
in helma.

Reg. the helmaLib module: Imo it shouldn't start with the mutation of a 
custom library (be it of orf.at, knallgrau, systemone or any else) into 
the new "official" helmaLib. There is already a broadly used helmaLib, 
and development should happen based on it in a way described above. 
Hopefully a lot of issues addressed in all those custom libs will move 
into the helmaLib, but in many cases this probably won't happen without 
modifications. Of course this might mean refactoring work in existing 
apps, but the benefit one gains with that is one thing less to maintain 
(that's why i'm sure it will happen).

The helmaLib as i imagine it can't be a replacement for all those custom 
libraries, but it will hopefully allow them to focus on special needs, 
so i strongly believe that the helmaLib *must* be a common denominator 
in the same way helma core is (i'm absolutely sure that this is 
possible). And i personally have a lot of expectations in it.

robert

[1] Helma core for 1.x is a special case because of the monolithic 
structure of the code, which means that separating it into different 
responsibilities is nearly impossible. So this will most likely continue 
to be the one-man-show as it is now. But i'm confident that with helma2 
things will be different.

Michael Platzer wrote:
> 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
> 
> _______________________________________________
> Helma-user mailing list
> Helma-user at helma.org
> http://helma.org/mailman/listinfo/helma-user