On 2/5/2021 3:53 PM, Steve Lubbs wrote: > Just a thought. > > As part of an effort to enable volunteer extension authors would it make > sense to selectively approve extension functionality for inclusion into > AOO on a case by case basis? If it provides a level of new functionality > that is considered important and compelling, say something that is on > the wish list and that no one has the time to pursue? For instance a PDF > importer that was mentioned earlier. > > With the author's permission and effort the extension could be ported to > be core code rather than an extension. The author, upon agreeing to > these conditions could be given the right of first refusal to be the > maintainer of the code. There should also be a proviso that the author > will to do the port. > > This, or some permutation, could be one way to reward extension authors > for their efforts, provide incentive, and provide new supported > functionality within the constraints of limited resources. > > It goes without saying that this would need to be carefully managed and > some way to vet the new code would be needed. > > Like I said, just a thought. > > Steve
That could be difficult, as right now extensions authors are free to license there code any way they like. To bring it into the core code of the product would require it be under the Apache License 2.0 (ALv2), and could require a signed Individual Contributor License Agreement as well. Regards Keith McKenna > > On 2/1/21 5:06 PM, Carl Marcum wrote: >> Hi Peter, >> >> On 2/1/21 1:46 AM, Peter Kovacs wrote: >>> I have a question. How much willing are we to support extensions. >> I think for extensions like report builder where the code is donated >> and it's a high-profile extension it makes sense. >> Much more so if we build and bundle during a release. >> >> Freedom to do releases is another issue. If they're AOO sub-projects >> we need to do the releases the same way as the Office and that can be >> cumbersome for something as small as an extension when they are done >> independently and frequently and most members may not have the >> toolchains setup. >> >> I ran into this with things like the NetBeans plugin and some other >> developer tools. >> >> I think for the same reason ASF wants a minimum number of developers >> for a project, a lot of extensions are probably one or two developers >> and we could end up with a lot of abandoned code. >> >>> >>> I mean we have here a voice recognition questions, there is the >>> reporting tool or wiki extension. >>> >>> We already thinking on creating repos for reporting tool or the wiki >>> extensions. >>> >>> But how do we deal with those topics on the organisatorical level? >>> >>> Do we form I do not know how to name them, task force around them? Do >>> the people who whish to be delevop these functions do this in an >>> outside project (independant if this is a Apache project or github >>> self sufficient hosted) >>> >>> >>> I would opt that we agree on some form to enable volunteer to use the >>> project infrastructure and provide them with a stronger feeling that >>> they are part of the project even if they are only working on an >>> extension of none core features. >> >> For most extensions I don't think this is necessary when they have >> GitHub, Sourceforge, etc. >> >>> >>> This makes it easier to bring the community together. I mean the >>> wording 3rd parties bring a lot of discussion and the need to explain >>> things, to the table. >> >> I think there are things we can do as a project to support a community >> which we need to grow. >> Some of which like forums and mailing lists we already do. >> Extension developers are welcome on the dev@ list. >> >> There is an api@ list for that purpose but I thought it was shut down >> for lack of traffic and I didn't subscribe anymore but I see there are >> a few recent posts within the last year and almost no replies to them :( >> >> Jörg had some good points about Extension Manager support and other >> tools for extensions and you may know I'm working on new extension >> creation tools as well. We can also make sure the Developer Guide is >> up to date and things like that. >> >>> >>> >>> I am just wondering what everyone else thinks. >>> >>> All the best >>> >>> Peter >>> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org >> For additional commands, e-mail: dev-h...@openoffice.apache.org >>
signature.asc
Description: OpenPGP digital signature
