Re: [Openinteract-dev] What is OpenInteract2 ?

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

Teemu Arina wrote:
>>> Well what I was thinking was more in the lines of OI2 not being even 
>>> partly a CMS.
>> 
>> I'm sure you can mold OI2 into whatever you want it to be... :-)
> 
> I believe that for a project to become _the_ option for a certain target 
> audience, it should state it's mission and roadmap pretty clearly. This 
> builds up confidence in the platform and provides an answer to the most 
> important question: ok if we start to use it now, how is it going to improve
>  and in which direction?
> 
> Answering, that it can be anything you want it to be is pretty confusing.

Argh. I was trying to avoid the public relations discussion... :-\

I'll try to rephrase a little..

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.

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

If we hace a quick look at the state of OI2 (today), it may look something like
this - AFAICT:

   1) OI2 is Big and Complicated
   2) Although the beta period for OI2 has lasted forever(tm), there's still a
      large amount of bugs (currently around 60 in JIRA). :-\
   3) OI2 has some good "infrastructure" features but few "application"
      features. Developers like the former, users the latter. Who's more
      important?
   4) OI2 is pretty well documented (I'm guessing 75%), but lacks a lot of
      common things that make large amounts of information more comprehensible
      to the reader (e.g. ER diagrams, class diagrams, data flow diagrams).
   5) The OI2 community is too small and quiet. :-(
   6) Contribution to the project is difficult - perhaps due to social quirks
      (shyness of speaking in public fora? our inability to follow up requests
      on this mailing list? the "Jante law"?), but also due to technical
      complexity (finding where to add a feature requires a lot of digging).
   7) One _can_ say OI2 has a lacking webpage, unclear about mission and
      perspective.
   8) We have an underutilized wiki (is anyone actually reading or using it?)
   9) The mailing list archives and bugtracker have little sense of connection
      between them, the website and the wiki. What can we do to make all this
      information less fragmented? Is there a way we could integrate JIRA with
      the main site? Or use a OI2-native wiki instead of TWiki?
  10) We have only a vague sense of what kind of audience OI2 is for. It seems
      to be mainly for advanced web application developers, but we'd like more
      people to use it, right?
  11) Chris has always been doing most of the significant development, but like
      the rest of us, he's swamped in distractions from from doing the Important
      Stuff - namely improving OI2. :)

All these points lead to interesting project questions. Ask yourself these
questions, find if some of them interest you, try to answer these, and finally
try to implement the answer. (And should you come across something that stops
you from implementing it, then fix that first)

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


> Let's revisit openinteract.org first paragraph. Let's call it the mission 
> statement:

[deletia]

Sure. Fix it if you have access, write a bugreport if you haven't.

Chris, is it feasible to give people access to improve the website?


> So if it's intended as a base for web application development, then why on 
> earth does it require you to install an CMS you might have no use for?

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?

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?


> All the other functionality, like security, user/group management, UI 
> widgets etc. are very important for web application development. Higher or 
> more specific implementations should be optional.

Sure. Sounds reasonable. If they're not optional, they at least have to be easy
to uninstall, and doing that shouldn't break anything.


> Although the lower level functionality is important, sometimes these also do
>  not serve the purposes. We replaced/extended most of the 
> user/group/security stuff in our OI2 application called Dicole (demo at 
> http://dicole.net)
> 
> [...]

(A little off topic here: I think it would have been _much_ better if you
improved OI2 instead of replacing parts of it. :)


>> They're there so you can get a notion of what's possible to do OI2, and 
>> when you've seen _that_, the _real_ big questions show up: How can I use 
>> OI2? How can I improve OI2? What should be improved? How easy is it to 
>> improve OI2? How can I make it easier to improve OI2? What should be 
>> improved so OI2 becomes easier to improve?
> 
> These questions can be answered if the base installation greets you as a web
>  application framework and not as a generic CMS.

Sure. Fix it if you have access, write a bugreport if you haven't.


> Despite some things I'm not happy with, OI2 is still the best decision we 
> have made when we looked for a new base to build upon. We have done more 
> during this time for our customers than we could have done without. The 
> design of the web application framework is brilliant and I'm happy to help 
> it to be even better.

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.
This would in the long run mean less maintainance, more user feedback for you
(assuming OI2 becomes as wildly popular as we'd like :) ) and more
out-of-the-box and Good Stuff to impress people with. :)

(Enough ranting! I realize I may be a bit boastful for someone who's
contributed as little as I have, but please ignore this fact and see if any of
my points are valid anyway. :)


- Salve

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