OpenAmiga.org: the future of the project

Let's face the truth: the OpenAmiga.org project has run aground. There is currently zero activity; there is a host of projects with unclear status; much-needed and realistic projects are mixed with mere would-be-nice-to-haves, etc.

I think we're losing huge potential there. The AmigaOS4 development could get a nice speed-up if (according to OpenAmiga.org's original mission) third-party components found their ultimate way to the OS: datatypes, BOOPSI classes, dockies or various commodities, pieces of documentation are perfect examples.

One way of looking at the current situation would be "OK, so why don't the developers take up the suggested projects and do them? It's their fault!" That is indeed a valid point but I'm afraid it does not cut to the core of the problem.

The problem is that projects are suggested, described and assigned priority by individuals outside of the OS developer team, which does not make any sense. Take, for example, the suggested and allegedly assigned (but now apparently abandoned) project "Message subscription broker". It surely describes a nice idea but: who asked for it? How realistic is it that Hyperion would ever include something like that as part of the OS? Who assigned it high priority? If it is really high priority, why is there nobody interested in what the project is doing? Etc.

Please note this is not to criticise Orgin or the people who suggest/have taken up projects. This is merely to point out that unless OpenAmiga.org is re-focused and given due relevance, nothing much useful will come of it.

OpenAmiga.org presents a great opportunity for Hyperion/OS Dev Team to say: "OK, we need this but we absolutely lack time to develop it. Here's the specification, somebody please grab it and do it for us." For the interested developer this is a completely different situation: if I know that Hyperion really needs this, and that I won't be spending weeks working on somebody's pipe dream with zero chance of being incorporated in the OS, my motivation for taking up the project is on a completely different level.

Bottom line: I'd backup the whole thing, close all suggested and apparently inactive projects, and let Hyperion tell us what they really need. People would still be able to come up with ideas for projects (Steven Solie is easy to contact, isn't he?) but it's the Dev Team who should assess if the suggestions are needed, relevant and realistic. I'm quite sure we'd get much further with this new approach.

My two cents, now please discuss

I have some projects hosted there which, although they don't see much activity, I do commit to from time to time.
I think part of the problem is projects *look* dead. What's needed is a "recent activity" thing which looks at the last SVN commit time. (we may then see that all the projects *are* dead, but that's another matter entirely).

@Chris

There's no problem with "slow" existing projects, and no one's of course saying they should lose their hosting there! It's about a new direction for OpenAmiga.org as a whole.

This could also give a new lease of life to the dormant AmigaBounty.net, as priority OpenAmiga projects could be coupled with respective bounties to enhance developer motivation.

It's not all dead, it's just that most activity is in the SVN and not on the web site. Granted a lot of the suggested projects are standing still but that's not the whole picture.

I don't think it's a good idea to only focus on things that Hyperion comes up with or what they perceive as important. People must be allowed to come up with ideas that no one at hyperion has dreamed of.

Not that I would mind if someone from the internal development team gave some feedback in the form of a priority rating on the existing projects or if they posted their own projects. Nor would I mind if they gave feedback on the description on the suggested projects.

Point is, we'd need both motivation by sheer creativity and hyperion prioritizing.

I'd also like more people directly involved with openamiga itself and not just developers in the different projects. With more people coordinating things it's easier to attract more developers.

@orgin

Quote:
That's true - although such project suggestions should be given informed feedback to ensure they are a) needed, b) realistic, c) apt for seamless integration with existing system components. Project specifications should especially be reviewed by the Dev Team/experienced developers to avoid misimplementation and future problems. (Looking at the "Message subscription broker" project again as an example, you'll see that the project wants to develop a special library through which applications will subscribe to events from the broker. Is this a good idea? Can't this instead be incorporated in the Application Library, which already features a complete messaging framework? These are the questions that the review should answer.)

Quote:
I believe these two things are interlinked. If it is clear that a project is needed, asked for and properly specified, interested developers are much more likely to feel motivated for taking up the project.

Quote:
Well it was me who started this whole rant so I had better stand up and volunteer, right? OK, I'll see what I can do.

Imho one of moments is that on main page there is nothing like "recent activity" (or it even should be as some big size form in the main page) , where ppls can see on what projects and when commits done, and so on, so it will be visibly that activity is going on , and will bring some motivation together with interest to join. Because as it now, its indeed looks "dead" for outsiders, because there is just list of projects.

In other words, adding recent activity on main page for all newcomers without needs for registration will help a lot (imho).

@kas1e

I'll see if I can find time the coming weeks to add a recent SVN commits feature.

@orgin
Quote:
I agree. 3rd party developers should never be limited.

I'd like to point out that Hyperion is the owner of the operating system. It is the AmigaOS development team that decides where the operating is going. Perhaps the AmigaOS Development Team Lead would be the person to contact in regards to prioritization and what not...

@ssolie

Quote:
Anything that will establish a closer contact and cooperation between the Dev Team and the OpenAmiga project is a good idea, so if you're saying "send your project suggestions to me for review", you'll have them

I can help out with coordinating this if Orgin wants to focus on managing and improving the site.

@ssolie
Quote:

Some ideas:

1. Make sobjes to be real shared and add versioning like in shared amiga libs. Also fix SDK to not build everything with sobjes by default, but only when developer want it. Sobjes can be good, but when they will be really shared. Right now we bring bad features of sobjes (".so mess"), but not bring good ones (be really shared). And only real pluse of having it its easy porting of linux apps, but .. as we can see, in end it not give us any benefits mostly and we all ends up with native apps and want exactly them. So maybe its time to not move more on linux side, but instead concetrate on our own good things (usuall amiga libs).

2. I feel there is fear to restructure whole PREFS thing. Its mess now: half should be merged together , some renamed, some resturctured, some just removed. That need discussing and do things in that direction. Firstly discuss it privately, then publicaly, so before starting to implement changes discuss it with registered users as well.

3. Found more devs to works on Workbench and on AmiDock : Amidock need improvements and fixing (most of reported in BZ already). And Workbench need real improvement: for beginning, all the stuff like AsyncWB, ContextMenus, Click2Front and some other : all should be integrated into WB directly, and there no needs to have it all as commodities, just as options in WB. Besides most of them running by default, so why user need to think and know about it at all. After all the stuff will be integrated in WB which is commodities now, there can be improvements in terms of main listers.

Sure code of WB can be boring and old, but we have nothing else, and as it default, and we for sure will not have our lifes to replace it in accesable timerate , then better to improve it even a bit , even old code, in compare to not do anything with it.


4. And in end of all, attact more developers to os4 dev team, without making them waiting long-long time. Giving all the right ppls access to all source code. Not like "i will give you only accesess to that or that", just give more ppls access to os4 code. I talk for example about Trixie: he logical and adequate and will help a lot. As well as ChrisY. As well as somehow try to motivate Thomas and Gazelle, they also skilled pretty well. And there for sure some more, but need motivate them somehow to join.

@Trixie
I would like to try and help coordinate things on the OpenAmiga site with what the OS team is doing.

Let me know what you need and I'll see what I can do.

P.S. Email is still the best way to contact me. I do keep an eye on the support forum and amigans.net but I don't generally read much else.

@kas1e
Beta testers should be using bugzilla and the closed beta testing forum to discuss such matters.

@ssolie

Quote:
OK, I'll sum up my ideas and contact you via e-mail

Btw, I sent you an e-mail three days ago with some questions concerning the Application Class I'm currently writing. Have you received it? People have been reporting that my e-mails sometimes end up undelivered when sent via my Liverpool home ISP (whereas they get delivered OK when sent from the university).

@kas1e

Quote:

The SDK (or really gcc) does not do this. You have to explicitly add the various shared options to build shared objects and then link executables with dynamic linking.

Hi, I see openamiga a nice place to upload my little tools/dockies to openamiga so people can see/(ab)use/fix source code

@ssolie
Quote:
If it will be only my single post, and no one will talk about, you will just skip it , and all those ideas will die, and you will think "right, its only kas1e think like this, all others are ok as it now, so let's skip his ideas".

And imho there nothing "private" in what we discuss. Usuall user wishes. All that "talk with me directly in mails" , will lead to only "i do not want this , i do not want that, i will not do that, i will not change my mind, you wrong, i see no reassons for that" and so on. While when many ppls will support some of my ideas, you will see that its indeed right (or not).

More public discussion help our OS to grow. More "private only with me in mails", make it slower to grow and only make your ego be happy :)

@Andy
Quote:

There was quite some scenarios when i previously have everything builds with sobjs and automatic addons of -dyn-ld in makefiles when use configure scripts, even if add to them that all should be builds statically. I can't right now remember and check it all (not at home), but if there is needs, i can found and remember moments when -dyn-ld automatically puts and uses while should't.

@kas1e

Quote:

That's entirely down to the configure scripts, nothing to do with the SDK. One of the issues with porting is that you need to fix the configure scripts non amiga assumptions. Whether that be by fixing the script istself or by ediring the resuatant config.sh

@Andy
Quote:

Like i do not know how to deal with porting :) Sure i know, and deal with hundreds of ports already, but my main point is that sobjes in their current implementation do not give us any benefits except easy porting of linux apps, but, as we can see in end, we all prefer our sw be as much native as possible. From all linux things we have in os4, only one good one is ELF bins. GDB is may be good, if it wasn't so buggy and non-usable sadly. And sobjes "half" done (non shared, while their idea be shared).

And today our SDK are full of "support sobjes" moments and 3d party developers offten use them, but there is no needs at all for them.

I remember i found some things (not related to configure scripts at all), when sobjes was in use anyway, and only to get rid off them i was in needs to use "-static" for linker. I can't say exactly right now, but there is moments when sobjes in use by default, even if i just compile program manually from shell, without adding -dyn-ld, and only way to make app without usage of sobjs is add "-static" (as i say no related to configure scrips as well, just pure single source file).

I can do more test and remember all of this, if there needs and interst to deal with, but i assume it will ends up as it now, and so , better solution imho will be to make sobjes be really shared. As well as add proper versioning like in real amiga libs. Imho versioning can be easy to add , just one more field in sobjs somewhere, and add checking in elf interpretator on (or what handle sobjes first, not so matter). And just make an article called "aos4 differences in sobjs implementation" where point what new fields added and how they parsed.

For example if sobjes will be really shared, then QT apps will runs almost like native by speed: for users will be enough on loading of os , load necessary qt sobjes to memory from user script and everything will be fast on running. But now, for running every QT app we wait till everything loads in memory again and again.

@kas1e, broadblues

Looks like we've rambled rather off-topic. Let's focus on OpenAmiga.org - if anybody has any ideas or comments, please join in.