> On Tue, 2007-02-20 at 13:53 -0500, Robert Carr wrote:
> > At the very list I agree a common mailing list would be a good idea.
> >
> > The license issue is possibly somewhat difficult, most of the Beryl
> > developers would be fine with MIT but I know of at least two who would
> > have problems, notably Quinn, I think Quinn would be willing to flex.
> > I think core could be made even smaller in the future (functions such
> > as moveWindowToViewportPosition are a great example, this could be in
> > some sort of library) and this would be even less of an issue. In
> > general I think Beryl would be willing to compromise on this point.
>
> Normally, those who contributed most code, got most to say about
> licensing. That should apply here too. If those who contributed most
> code to the core are OK with MIT, then there shouldn't be a problem. As
> I've written significantly more than 50% of the code in the core, I
> believe that I'm in a position where I don't have to compromise on this
> point.
>
Like I said, I don't see MIT as a license being an issue.
> >
> > I definitely understand your reservations with core under a different
> > name (If it were my project I would likely have the same). However I
> > think a new name might be somewhat important, a merge under the Compiz
> > name would alienate large portions of the Beryl community, and
> > potentially cause a lot of issues. We obviously both know that the
> > name is not that 'important' to the success of a project, but
> > realistically a large portion of the Beryl community ( and a larger
> > portion of the Beryl development community ) would more or less insist
> > on a new name and it would be viewed as a great compromise. I think it
> > is the difference between 'Beryl gives up' (Very much not the case)
> > and 'Beryl and Compiz realize they can accomplish much more working
> > together' (I hope this can be the case).
>
> How many developers are working on the core? Do you think a lot of
> plugin developers would care about the name of the core?
>
Quinn, onestone, Kristian, and I are really the only ones who work on
core anymore. It's hard to say how many plugin developers would care
about the name of the core.
> >
> > I do not think many people would be interested in all plugin
> > development to a new project with a new name, and really I think the
> > difficulty and wasted resources in maintaining two separate projects
> > such as that would be more difficult than it is worth.
>
> I don't agree. I think a big problem right now is that plugins are part
> of the core project. The core project should be small and simple to
> maintain. There's not going to be a huge amount of developers working on
> the core.
>
> I want to make sure that people can go create their own plugin projects
> and not necessarily feel that their plugins need to be part the same
> project as the core. As long as some plugins are part of the core
> project, there's going to be a problem with this.
>
I agree there is an issue with people feeling their project need to be
part of the same project as the core, Beryl has an (in my opinion) bad
tendency of accepting EVERY plugin.
At the same time I feel a few of the following things make having core
and at least some plugins being a part of the same project sensible.
1. Bugs in core are found through plugins. If they are under one
project it's easier to manage and fix such bugs.
2. Users. I do not think users would like "Go to one site to get the
core, then go to the other site to make sure you can do anything with
it."
3. Developers of plugins will have insight in to decisions that need
to be made about core.
4. Synced releases.
5. Plugins have to be updated to changes in core.
In my opinion at least some plugins (beyond move/resize/place but less
than what Beryl has now for example) makes sense to be developed under
the same 'Envelope' as the core project, with a possible strict policy
of 'No new plugins' unless it is a proof of concept of a new feature
in core.
The way I see it things would happen as follows:
Project A distributes just core with no plugins.
Project B distributes 95% of plugins used with core. Projects C, D,
and E distribute the other 5%.
So everytime a new feature or change in core occurs the following happens:
Project A lets Project B know and appropriate changes are made.
Information dessiminates to projects C D and E.
And everytime a user desire to obtain the software the following happens:
User finds project As website, downloads core.
User realizes they need plugins, asks around, finds Project Bs
website, installs Project B.
Over time a user finds Projects C D and E and finds a few new plugins.
To me it makes more sense for Project A and B to be the same project
in name, infastructure, etc.