Re: [Openinteract-dev] What is OpenInteract2 ?

[Salve J N. <sal...@me...>]

[Sorry for the verbosity of my ranting :)]

Antti Vähäkotamäki wrote:
> Salve J Nilsen wrote:
>> 
>> [snip]
> 
> Also I think that it is very hard to make something easy to develop if there
>  are no guides on what is the preferred outcome. It's like coding with bad 
> specs - you hack up something and hope that it is suitable. This is not a 
> good way to encourage contributing to OI2 itself.

I'm of course assuming the contributor has some common courtesy when it comes
to submitting significant changes (but since assumption is the mother of all
fsck-ups, we make sure CVS is there to save the day. ;-)

Anyway, I'm trying to postulate that motivating people to do something is much
more difficult than deciding what to do. To do the latter, one only has to have
a look at JIRA to get started, or try to take notice of things that are 
difficult to do when creating an OI2 app (I'm sure you can think of more)...

Since we're talking about an Open Source project, we can basically say bye-bye
to extrinsic motivational tools like salaries or the threat of layoffs. This
leaves us with the intrinsic ones, which basically have the drawback of being
highly personal, e.g. the wish to write good code, scratch your itch, help a
friend, pride, reputation or self-education. From the project's point of view,
I'm sure we'd like to allow everyone to make use of their motivation as they
seem appropriate, and AFAIK, the most sensible way to do this is to have an
"including" demeanour towards those who want to contribute - giving them trust
and responsibilities - and to reduce the number of hurdles one has to jump
through in order for someone to actually make a contribution. (I'm sure there
are more ways.)

If we manage to arrive at this point (no hurdles, positive community, etc.) I 
think we're basically members of a do-ocracy - "Just do it, we trust you!".
I think that's a good thing. :-)


> [snip]
> 
> I think this is the best way we can help OI2 to advance as a project since 
> the more people write their applications on OI2, the more we can identify 
> places where OI2 should be developed futrher to achieve our mission - and we
> will probably even get help for doing it.
> 
> I think that if OI2 has no clear mission, everybody will concentrate more on
> building their own missions and OI2 will always remain just half made 
> everything.

Sure. Do you have a suggestion for a mission statement? :)


>> OI2 is an open source project, dammit. Why bother with the self- 
>> scrutinizing philosophical questions when we can change the world with 
>> code? We _have_ the freedom to do watever we want, and _that_ is why I'm 
>> sure you can mold  OI2 into whatever you want it to be... :-)
> 
> Open source project is just like any other project: to succeed it needs good
>  management. Lonesome coders hacking away as they see fit is not going to 
> end up being everything we all need.

If you think you're a lonesome coder, then I'm sure you actually are. If you
feel you need management, then I'm sure you actually need management. But if
you take the time to count the members of this mailing list, you'll quickly see
that you _aren't_ alone (even if we're a quiet bunch), and if you try to do
something that's useful for OI2 all by yourself, I'm sure you'll see that we
cab be quite positive to your contribution (if we find the time, we might even
comment and critique it. :)


> We need to discuss the directions where we are going so that we can benefit 
> on each others work. I can write a million hello worlds within an hour by 
> using OI2 and some code generation, but it is not going to change the world.

Just tell us what you're doing.. ;-)


>> Chris, is it feasible to give people access to improve the website?
> 
> To suddenly change the mission statement the way one wants it instead of 
> discussing it with all the others first? ;)

If you feel like being efficient, then sure. Just make sure it's an obvious
improvement. (Otherwise we'll revert it and remove your write access ;-)


>> What's more important? That new users and developers can get a site up and
>>  running easily, or that experienced developers have a "clean install" to 
>> work from?
> 
> In my opinnion both are important and they are in no way conflicting goals. 
> Ofcourse it is very important to have example code or even an example system
> you can build upon if it _happens_ to fit your needs. But building upon the
> example code should IMO not be the expected usage.
> 
> I think the expected usage should be that you pick a collection of the 
> example modules you need and build your application using those.

My experience is that one shouldn't expect a specific kind of behaviour from
users... Why not just "expect people to use stuff in new ways", and make sure
the APIs are consistent and clean, everything is subclassable, neatly
modularized and all significant events are logged? I think that would be a nice
start, at least. :)


>> Should OI2 _only_ be an application framework, or should it also be usable
>>  ("out-of-the-box") as a corporate intranet? Or a collaboration tool for a
>>  volunteer organization? Or a generic frontend for a database? Should we 
>> be allowed to choose?
> 
> I think OI2 should be _only_ an application framework. Simply said.

Then I'm sure you'll commit code and report issues so OI2 moves in that
direction. :)


>>> Although the lower level functionality is important, sometimes these 
>>> also do not serve the purposes.
>> 
>> (A little off topic here: I think it would have been _much_ better if you
>>  improved OI2 instead of replacing parts of it. :)
> 
> What do you mean by improving OI2?

Anything that you have found lacking in OI2 and fixed in your app, could be
made part of OI2 in the core (or as an easily accessible option).

E.g. if you find that the security system is too slow (and determine the reason
is the amount of database access), then you could create a drop-in replacement
for base_security (or whatever is appropriate) so other people also can get the
option to use your "base_security_fast" package. Or you could write the
documentation (to be placed in the as-yet non-existent OI2 HOWTO) which
describes how to configure OI2 to cache security lookups better or how to
create applications that access the slow security features less often.

I'm just making things up here, but I'm sure you understand what I'm trying to
say: When working with an OSS framework, the framework's value grows faster
when everybody involved tries to improve the framework for the general case
before creating the "special case" solutions.


> We have only 2 patches against the OI2 cvs tree, of which one is already 
> obsolete because of the changes in OI2 tree and the other is already 
> reported in JIRA and is being discussed - we can't just go and commit the 
> code before discussing with Chris even if we have commit access to CVS.

Chris is busy. Should everything really have to stop because he has something
else to do? (BTW, This looks like a classic single point of failure scenario...
:-\ )


> Then we have our own version of many of the factory classes in OI2, but even
>  many of those changes are either discussed on the dev list or reported in 
> JIRA as change suggestions.

Do they solve some general issues? Can the classes you've made be generalized
enough to be included into OI2? Have you attached the code you've made to the
JIRA issue, so others can have a look at it? :)


> Then we have some packages which are used to test some approaches and which 
> in the end _might_ end up into OI2 as ideas, but are currently implemented 
> so that they are not near generally usable. On the other hand they might 
> provide to be immense crap.

Publish them on your own webserver, and let other people decide. Set up a new
category in JIRA, and create an issue there, so people can give structured
feedback. Find other ways to tell us what you're up to. :)


> Also there is lots of code which will never find it's way into OI2 because 
> it's application specific. I very much doubt that Chris would want our 
> bloated security framework into OI2 since the whole structure is heavily 
> dependent on our applications view on groups and users and we ignore SPOPS 
> securities for management reasons.

Hm. So you're creating boated application specific code? Tsk, tsk. (BAD
developer! Now go and read "Big Ball of Mud" and "Code Smell" ;-)


> On top of our specific focus, we have limited resources and tight schedules,
>  like everybody in this business has. We just simply don't have the time to 
> plan and test our approaches as long as we find a way that might be 
> integratable with OI2. Usually the good ideas grow in time and they need a 
> lot of experimenting in different directions to evolve to a general state. 
> We can't just decide that we will make everything as general as possible to 
> be incorporated into OI2 core even if we wanted to. We do what we can given 
> the resources, but usually the output is far from general and reusable 
> Brick. When it evolves, maybe?

Well, I hope you'll find the time to make your code general enough for OI2,
some day... :-)


> But the sad fact is that we can't dump the customers who pay our bread to go
> on a crusade to build a better world - we are already making as many stabs
> as we can towards that goal.

So your customers aren't interesting in building a better world? (Just kidding. 
I'm sure you try as best you can. :)


>> For example, find the parts of Dicole which are (almost) general enough 
>> for everybody to use, and find a way to move it out of Dicole and into OI2
>>  instead.
> 
> We can't just decide ourselves that OI2 needs this and that and completely 
> wreck the CVS without asking anyone. We have to discuss and agree about 
> things - like the things we are talking about in this mail thread.

You could start by creating a separate branch in the OI2 CVS for your 
experiments... :)


- Salve

-- 
Salve J. Nilsen <salvejn at met dot no> / Systems Developer
Norwegian Meteorological Institute           http://met.no/
Information Technology Department / Section for Development