Re: [Openinteract-dev] What is OpenInteract2 ?

[<an...@io...>]

Teemu is on a vacation this week so I'll try to answer for him since I 
think this is quite an important topic.

Salve J Nilsen wrote:
> Basicly I agree with you, but I also think the question of "wether or 
> not OI2 is a CMS (or has a clear end-user decipherable mission statement)" isn't 
> the most important question at this stage. Today, I think we're much better 
> off if we try to make OI2 as developer-friendly as possible.

I think Teemu was trying to say that setting goals and guidelines is a 
very important part of making OI2 developer-friendly. I agree that is it 
mainly important for the end users who write their applications on OI2, 
but the fact is that we will probably never get people on board who are 
just OI2 developers - their motivation will always (at least in the 
beginning) be their own application which runs on OI2. It's just the way 
open source projects usually work.

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.

> To do this, it may help to point out that OI2 isn't a _product_, but a
> _project_. Asking product questions (e.g. "Does it do A") can be useful, but
> not nearly as much as asking project questions (e.g. "Can someone help  me write
> feature A" or "How can we make it easy for someone to write the A 
> feature").

OI2 might be a project but that does not mean that every piece of code 
written on OI2 should part of that project. OI2 is an excellent platform 
to extend in the direction of your needs, but those developer needs 
which aren't already addressed by OI2 are hardly ever general enough to 
be used by most people who might benefit from building their application 
on OI2. For this we have packages and an excellent management framework.

The questions from the people who are interested in OI2 are more 
probably going to be: "How easy does using OI2 makes it for me to do A?" 
and "Has someone already done A on OI2 and could I benefit from it?" and 
thus these are also the questions we should be thinking when we develop OI2.

A huge part of addressing the first question id to provide a clear, 
detailed mission statement and a bug repository + documentation stating 
which features are missing or buggy and need more work.

The second question can be addressed by providing a repository of easy 
to use packages or compilations of packages, which can be adapted or 
extended to your specific needs.

Answering to the second question is IMO not part of actual OI2 
development, but it is a vital part for OI2 to success as an application 
platform. I think we should make it an another project which would build 
OI2 packages that provide different functionality and then compile a 
demonstration application(s) from these packages for OI2.

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.

> 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.

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.

> 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? ;)

> 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.

> 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.

I think that if you have built up a corporate intranet on top of OI2 you 
should name it OpenInteract2 Corporate Intranet and publish the 
compilation of packages you have used in a different site or a project 
hosting OI2 apps, which OI2 site can then link to so that those building 
their own corporate intranets can have almost out of the box 
functionality, but those who are building a frontend for database don't 
have to mind their head if they can remove your corporate intranet 
package XY from their fresh website install without breaking the whole 
system.

There are unlimited uses of OI2 and many of them DO conflict with each 
other. This is why none of them should be included in OI2 base install 
but somewhere else.

>> 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?

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.

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.

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.

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.

If somebody, for some reason, needs similiar group and security 
implementation, they are very welcome to check what we have done. It's 
in the CVS and it's very liberally licenced. But it definately is not a 
general approach that should be provided as the default one for OI2.

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? 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.

For example we are not just trying to persuade you to see OI2 as solely 
an application framework just because we use it as one. We think that it 
would be the right thing to do for most of OI2's users.

> Just do it...
> 
> 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.

What makes you think that we are not doing it the best we can? The 
abundance of my oi-dev posts? ;)

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.

- Antti