Mark exactly hit the point I was trying to make. Imho, If I was joining an open source project, I would like to see availability for programmers to push any changes to any sub-area of the project without special permission of a higher force. My thoughts are striving towards decentralization here. But to make an order in such potentially chaotic conglomerate, "distribution(s) maintainers" would compose and offer what they think it is the best for particular use. Programmers would compete by code quality to be included in future parallel distributions, just like it is the case with Linux and its distributions. This idea sounds a bit progressive on the first look, but it might work. It takes some to implement it, but maybe some source control solutions that Mark proposed would be ready yet now, without a much an effort.
Just sharing some thoughts, someone might find it useful. 2017-10-05 21:49 GMT+02:00 Mark Nuzz <[email protected]>: > On Thu, Oct 5, 2017 at 12:10 PM, Ben Goertzel <[email protected]> wrote: > > "Modular" and "monolithic" are very general terms. Could you > > articulate more precisely the ways in which you think OpenCog is > > "monolithic", and in which you think it could be made more "modular"? > > > > My thinking is: the Atomspace is a distinct module (in its own repo, > > it builds separately, etc.), and the various AI processes that can be > > used with the Atomspace are also independently buildable and runnable > > (MOSES, PLN, the NLP pipeline, ECAN, etc.). Also when we use OpenCog > > for robot control, it communicates with other AI tools that are > > wrapped up in separate ROS nodes. This already seems pretty modular > > to me. So I am wondering what other kind of modularity you are > > looking for? > > That's good news. My views are that this architecture needs to be > developed further in order to reap the full benefits of it toward the > project's goals. > First and foremost, why are the independent processes part of the main > opencog repo and not managed as separate projects with their own > versioning and dependency toolchain? Do we have a fluent understanding > of the pros and cons of doing it this way versus separate > repositories? My guess is no, not because the team isn't smart, but > because the resources seem to be focused on the specific modules > rather than the architecture as a whole. But I've learned not to ever > underestimate the expertise of the team so this is just a wild guess. > > By dependency toolchain, I'm only aware of robust tooling for systems > written in a single language or framework. Examples are npm, nuget, > rubygems, paket. This reddit thread suggests that C++-based package > management is a hard problem, and I'm inclined to agree. > https://www.reddit.com/r/cpp/comments/3d1vjq/is_there_a_c_ > package_manager_if_not_how_do_you/ > However, it may still be worth trying. > > The vision that I have with this -- and this is the key point -- is > that by keeping the modules as separate projects, the perceived > complexity of the system is greatly reduced. The intimidation factor > is reduced (for anyone new). The build tools can be simplified. Each > project can have a concrete release build with a semantic version. > Docker images could be provided, with pre-built binaries, for each > major release. Each separate project could be developed independently > with the assumption that your only required dependencies are those > which are the latest major releases, and therefore if someone has > trouble building, for whatever reason, then they can resort to using a > docker image. Anyone who wants to work on a subproject can hit the > ground running as there will be more concrete releases. Version 1.15 > of a given project will always be version 1.15. The way I see it now, > is that we have a one-dimensional master branch for a large chunk of > modules that exist in the opencog repo, though I see there are some > efforts to do what I'm suggesting... so we might have the same vision > but with someone varying ideas on how to execute it. > > > > > > > Regarding Ivan's description > > > > *** > > I was referring to an imaginary system where the whole project would > > be a set of modules that work together, connected by well known set of > > interfaces. Each module could be modified or forked out in parallel > > with the original. It would be up to a user, which sub-forks she/he > > would choose to use to run the project, or to base her/his > > contribution on. Probably there would be a need for combination > > maintainers, something like persons that would choose different > > flavors of the project, and would propose their "deejay-combo" to the > > public, optimized for this or that use. Sub-fork combinations of low > > quality would be avoided, while really useful ones would live on. > > *** > > > > I guess one relevant point is that the different AI tools within > > OpenCog can interact in many many different ways. E.g. there is no > > single, simple interface for interaction between PLN and MOSES; there > > are lots of ways they can interface, conceptually speaking. And > > figuring out the best ways for them to interface is a current research > > topic... > > This is definitely relevant in the sense that it is easier for a > person to learn or understand this concept if looking at the project > in isolation. I.E. If the projects are separated, they are going to be > giving full attention to a project while reading it. If the projects > are merged together, there is a higher likelihood that one will skim > the documentation instead, and get a poorly understood concept of it, > possibly making mistakes later or failing to return to the > documentation a second time due to the perceived time sink (the truly > determined AI developer won't stumble here, but they are the exception > and not the rule). My crazy philosophy is that a new dev may start off > undetermined, and then if they are not overwhelmed early on, they will > eventually see first hand how awesome the project is, and then > everything will click, and psychologically speaking, the currents will > move with them and not against them while learning the rest. > > > > > In building a particular OpenCog application, one can define specific > > interfaces between the various AI components... But for OpenCog as a > > general platform, the interactions between the components have to > > remain flexible because there are so many interesting ways to do it... > > > > Package management and complete separation of modules into separate > repositories seems like the best way to do this, but if you disagree I > really want to understand why, as it could mean one of us has a deeply > flawed understanding of things and it could make for an important > revelation... > > > I think the biggest issue with OpenCog is that we need better > > tutorials and documentation. I guess if we had that people would be > > able to understand the system better and then would also make more > > useful suggestions regarding improving the architecture... > > > > Agree - Though this is also much easier to do under the conditions I > advocate. I'm trying to be careful not to make many rash assumptions > when making these suggestions, as I know that my understanding is not > nearly as high as it should be. The scope of what I am suggesting is > very narrow and specific to an aspect of the OpenCog architecture that > I am presumably aware of, and also is an aspect of software > architecture and psychology that I assume I have a strong > understanding with. > > -- > You received this message because you are subscribed to the Google Groups > "opencog" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > Visit this group at https://groups.google.com/group/opencog. > To view this discussion on the web visit https://groups.google.com/d/ > msgid/opencog/CAMyYmr97QJPEeEsGjG%2BQyC6xfujcPnX2L01ub4HpOxpZy8G > XaA%40mail.gmail.com. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "opencog" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/opencog. To view this discussion on the web visit https://groups.google.com/d/msgid/opencog/CAB5%3Dj6WeVGwgjZpHrkH9MandFQfHiefjW4vPcyzyKLgB3F2CZg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
