Create a WordPress bundler plugin with its own repository

[gusaus]

Just wanted to create the issue and have @majick777 wipe what I'm rambling on about and create a proper task pulling from the options presented in OpenProducer/newspack-platform#11 and OpenProducer/newspack-platform#11

I'll respond to a few points raised in the meta-discussion in the comments.

[gusaus]

@majick777 On the surface what you're proposing seems good by me! I think we're all talking about the same thing - problem again is I'm not well versed in the WordPress way and I probably should have said 'new plugin' rather than 'fork'.

Can I get a response from (both of) you as regards my proposal to create a simple bundler plugin, to install those list of plugins (call it RadioPack or something else Open Producer related) and then go from there with what else may be needed? Or does someone have a better approach?

Please note my answer is just surface based. I don't really have the headspace at the moment to even try to understand how the bundler plugin works. To me, I think of https://github.com/Automattic/newspack-plugin as a bundler plugin. The readme provides a pretty good explainer of what it does.

I'd like our bundler plugin to function in a similar way (pull in all the same dependencies - provide a dashboard - (our own) demo content - stuff that I was rambling on about OpenProducer/newspack-platform#11) so we don't have to rely on or include the Newspack plugin.

I could well be misunderstanding how it would work - I'm assuming we wouldn't need the Newspack plugin if our own plugin functioned in a similar way?

We probably should create a new feature request once we're clear on the best option and general approach. We should lay out the detailed requirements including a time and budget estimate.

I'd also like to make a decision on what to name the project and who owns it. Think I can just respond to OpenProducer/newspack-platform#11

I think Gus just wanted to call the whole thing, "OpenProducer"

No - we need to call it something else so we can totally decouple from the OpenProducer service described here https://github.com/OpenProducer/community

I'll create another issue where we can evaluate naming options.

and that would be the name of the plugin that installs everything.

If the plugin that installs everything = the bundler plugin that has a similar function as Newspack plugin, then yes. Are we in agreement there or am I still misunderstanding?

He's asking us if we want to make that part of our Git, so OpenProducer would live on the Netmix Git, be distributed as a WordPress plugin pushed through WordPress.org.

I don't want OpenProducer (the service) to own it. I don't want OpenProducer to own any products, we want to provide a service to them - including Radio Station plugin and whatever we're calling this one. My ask for Nemix to own it is more of an internal business decision... hence I created an issue in our private repo. I tried to provide a detailed explanation to why making a decision and acting really needs to happen this week https://github.com/OpenProducer/internal/issues/8#issuecomment-846270306

Not creating the new plugin - just settling on the name and ownership.

He's hoping to get FundOSS to put some dollars into this project as an open-source project only. There would be no PRO version.

Again I touched on FundOSS in https://github.com/OpenProducer/internal/issues/8#issuecomment-846270306. The main issues are

• we need to give FundOSS a heads up about the name and repo change once it's done (I'm already working w/ the organizers)
• we need to change the collective name (and add y'all to the team!) https://opencollective.com/openproducerplatform
• we need to do this as soon as possible so I can launch into full-on marketing/promotion mode beginning next week

FundOSS isn't giving $$ away - there's a matching fund, but the participants are driving their own fundraising. As the only WordPress participant... as soon as we can go public (i.e. new name and Github org) I'll be all over the WordPress community hyping us up!

Ok - I think that covers everything related to the open-source project. I'll followup on the business stuff in Slack.

[majick777]

Please note my answer is just surface based. I don't really have the headspace at the moment to even try to understand how the bundler plugin works. To me, I think of https://github.com/Automattic/newspack-plugin as a bundler plugin. The readme provides a pretty good explainer of what it does.

Yes Newspack is primarily a bundler plugin, though importantly it includes a setup wizard as well. But Im going to have to disagree on that last point - the Readme of Newspack does NOT explain much of anything - was a complete surprise to me when I tried it to have it turn out be a bundler installation plugin, or a setup wizard process (which I have yet to see the end of.) Just saying because if we are making something along similar lines, we want a MUCH better description than theirs so people actually to know what to expect.

I'd like our bundler plugin to function in a similar way (pull in all the same dependencies - provide a dashboard - (our own) demo content - stuff that I was rambling on about #2 (comment)) so we don't have to rely on or include the Newspack plugin.

Im not sure what the demo content is for Newspack or whether we even need our own. Personally think it is a waste of time - demo content sould be on a demo site, not preloaded in a fresh install making a mess you as a developer have to go looking around to delete. 2c.

I could well be misunderstanding how it would work - I'm assuming we wouldn't need the Newspack plugin if our own plugin functioned in a similar way?

Again this is where the setup wizard and configuration process comes in - work we dont want to replicate - which is why I suggested doing it the way I did... install all the plugins and hand over to the Newspack config wizard.

We probably should create a new feature request once we're clear on the best option and general approach. We should lay out the detailed requirements including a time and budget estimate.

Creating the initial bundler plugin using TGM Plugin Activation library based on the existing plugin list in Newspack would maybe take a few hours. Understanding what else Newspack setup does and whether all that is suited to what we want to do might take a lot more... Then there is adding our additional setup screen (before/after Newspack depending on flow and which way we can get it to work with it) so we can configure further any other stuff not handled by Newspack.

Honestly Im not really sure how to estimate time and budget at this point as it seems a little open-ended. Its a bit like trying to quote for a website proposal without having done the discovery phase. It would be great if we had the funds for doing discovery so we can plan this out better - or to be able to just dive in and see what we can do - but devoting discovery time to this on the possibility of funding is a hard ask while Im busy prepping Pro for launch...

If someone else had the time to delve into Newspack code itself and summarize for us all what it actually DOES under the hood, and what main features its core components (Newspack subplugins) bring to the table, and how those are utilized by its theme and child themes, that would be a big hurdle out of the way. Because as Ive said, I havent had time for more than a quick scan. That said, I could throw together the TGM bundler plugin pretty fast in any case.

[gusaus]

@majick777 Quick follow-up on the bundler scope and timeframe for discovery, funding, and development. If we can go into FundOSS (begins on Thursday!), with the consensus of name and approach (think we're on board with what @majick777 is proposing) we can make the funding and building one of the priority goals/outcomes for FundOSS.

It's also important we convey our desired approach to Newspack and make sure they have a good understanding of how they'll benefit. It might be quicker/easier to talk things out on a call or real-time Slack rather than going back/forth in the issue queue. Whatever is best for you and @tonyzeoli.

@tonyzeoli I also have more clarity on how we can direct funds towards add-on projects/features like this, independent of the collective associated with this Github repo and our FundOSS page https://fundoss.org/collective/openproducerplatform

We can accomplish using this brand new feature - https://docs.opencollective.com/help/v/v2/collectives/projects

We (OpenProducer, the service) needs to solidify a process for funded feature development https://github.com/OpenProducer/community/issues/13. Pretty sure we have all the tools to pull it off!

[gusaus]

Quick update on https://github.com/netmix/openproducer-platform/issues/22#issuecomment-855491548, I think we're on the same page with regards to naming https://github.com/netmix/openproducer-platform/issues/31

Basically, the bundler plugin name IS also the platform name.

The murkiness with the current openproducer platform is our bundler plugin does not yet exist. We're including Newspack, which is fine if you're spinning up a site for a client - not really good yet for an end user who might not think of enabling the 'Newspack plugin' or would get confused if their OpenProducer was called Newspack.

I think in the short term, we can just explain an official OpenProducer plugin is in the works.

This discussion is related in that it touches on how we use as an opportunity to promote and partner with Newspack - https://github.com/orgs/netmix/teams/internal-team/discussions/3

@tonyzeoli @majick777 Are we on the same page here?

[majick777]

As I noted in OpenProducer/openproducer-platform#31 it may be worth discussing further as regards server software (full Open Producer "platform") vs WP plugin bundling (just stuff for WordPress) though there may be little difference to begin with, the platform my later include other server-side software not installed by the bundler plugin.

[gusaus]

Are usually refrain from working during my morning walk. But we absolutely have to resolve any confusion between the three of us. Tony’s comment here hits home because the main intent of open producer has always been for it to be a sass offering.Not some thing that radio stations Or other groups in the media space would be looking for on get hub or word press.org. When I get home I can just share what we had ready to go before I realize there was no team to run the service. We had the product and Hosting everything ready to go. We have all that now but the difference is we have a team and Netmix as the for profit service provider. We also have two weeks beginning tomorrow to promote our products and services and onboard contributors or even team members. All that is on the I get ready for fund OSS discussion which I set up in the internal team

On Wed, Jun 9, 2021 at 3:27 AM majick777 @.***> wrote:

As I noted in OpenProducer/openproducer-platform#31 https://github.com/netmix/openproducer-platform/issues/31 it may be worth discussing further as regards server software (full Open Producer "platform") vs WP plugin bundling (just stuff for WordPress) though there may be little difference to begin with, the platform my later include other server-side software not installed by the bundler plugin.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/netmix/openproducer-platform/issues/22#issuecomment-857578984, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAA32TCHTLWGLKSIINIZR53TR46Y3ANCNFSM45UWYC2A .

-- Gus Austin https://openproducer.org/ https://twitter.com/getopenproducer https://twitter.com/gusaus

[tonyzeoli]

We are already talking about converting Radio Statoin to a SaaS interface but it will always need a WordPress plugin to display the data entered into the SaaS or to send data from WordPress into the SaaS.

Our first piiority is Radio Station. I would like to refrain from any discussion today about Open Producer as a SaaS We haven't rolled out our core product as PRO and I need to pleae keep the focus on that for now.

Everything anyone wants to do is:

a. dependent on Radio Stations PROs success b. based on that succcess, raising investment capital to build a SaaS solution, because a SaaS by its very nature is not open source.

So, let's table any SaaS discussions and focus on Radio Station PRO and FundOSS promo of OPP. We haven't even gotten any traction there yet, so it's premature to start discussion the ins and outs of what OPP should be until we see what FundOSS results in.

On Wednesday, June 9, 2021, Gus Austin @.***> wrote:

Are usually refrain from working during my morning walk. But we absolutely have to resolve any confusion between the three of us. Tony’s comment here hits home because the main intent of open producer has always been for it to be a sass offering.Not some thing that radio stations Or other groups in the media space would be looking for on get hub or word press.org. When I get home I can just share what we had ready to go before I realize there was no team to run the service. We had the product and Hosting everything ready to go. We have all that now but the difference is we have a team and Netmix as the for profit service provider. We also have two weeks beginning tomorrow to promote our products and services and onboard contributors or even team members. All that is on the I get ready for fund OSS discussion which I set up in the internal team

On Wed, Jun 9, 2021 at 3:27 AM majick777 @.***> wrote:

As I noted in OpenProducer/openproducer-platform#31 https://github.com/netmix/openproducer-platform/issues/31 it may be worth discussing further as regards server software (full Open Producer "platform") vs WP plugin bundling (just stuff for WordPress) though there may be little difference to begin with, the platform my later include other server-side software not installed by the bundler plugin.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/netmix/openproducer-platform/issues/ 22#issuecomment-857578984, or unsubscribe https://github.com/notifications/unsubscribe-auth/ AAA32TCHTLWGLKSIINIZR53TR46Y3ANCNFSM45UWYC2A .

-- Gus Austin https://openproducer.org/ https://twitter.com/getopenproducer https://twitter.com/gusaus

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/netmix/openproducer-platform/issues/22#issuecomment-857809720, or unsubscribe https://github.com/notifications/unsubscribe-auth/AA65WOYLDYOY4MLBSPQV3ADTR6DGBANCNFSM45UWYC2A .

-- Sent from Gmail Mobile

[majick777]

Sorry I didn't mean to derail this into a SaaS discussion, just wanted to note something on the technical front.

At the moment, to put it a different way (and I know you guys have talked about this extensively, so I am building on that discussion I hope not opening another can of worms) ... I see the OpenProducer Platform as a "distribution"... and the bundler (whatever it is called) as an "installer" package. So they would need to have different repositories - even though they are essentially the same project, the files are different. Similar to how a composer package ("installer") - installs the full software by installing the package and it's dependencies resulting in a full "distribution" package.

So while I do like the sound of "RadioStack" - I agree with @tonyzeoli that it really does make sense for them to have them same name. And I "get" that OpenProducer is the over-arching name and ALSO the name for the "Collective"... But given the naming conventions you've both discussed, just "OpenProducer" could still be the bundler plugin name.

Say as a slight alternative to what we've threshed out already, upon installing OpenProducer plugin it would ask you in the installation wizard, something like "What is your intended purpose for this website?" And then you could select any combination of "Newspack", "RadioStack", "MuzoRack" etc. as plugin packages that integrate for that purpose. Of course we wouldn't be doing any more than Radio and News related stuff at this point as we've all agreed to focus on those, but this model for the bundler would allow for that future thinking possibility - whether we ever implement additional packs or not. And it would mean if someone wants the Radio stuff without the News stuff, that become easier too.

[tonyzeoli]

Exactly. No need to add anything more from my side. You’ve hit the nail on the proverbial head.” We are in 100% agreement.

On Thu, Jun 10, 2021 at 3:14 AM majick777 @.***> wrote:

Sorry I didn't mean to derail this into a SaaS discussion, just wanted to note something on the technical front.

At the moment, to put it a different way (and I know you guys have talked about this extensively, so I am building on that discussion I hope not opening another can of worms) ... I see the OpenProducer Platform as a "distribution"... and the bundler (whatever it is called) as an "installer" package. So they would need to have different repositories - even though they are essentially the same project, the files are different. Similar to how a composer package ("installer") - installs the full software by installing the package and it's dependencies resulting in a full "distribution" package.

So while I do like the sound of "RadioStack" - I agree with @tonyzeoli https://github.com/tonyzeoli that it really does make sense for them to have them same name. And I "get" that OpenProducer is the over-arching name and ALSO the name for the "Collective"... But given the naming conventions you've both discussed, just "OpenProducer" could still be the bundler plugin name.

Say as a slight alternative to what we've threshed out already, upon installing OpenProducer plugin it would ask you in the installation wizard, something like "What is your intended purpose for this website?" And then you could select any combination of "Newspack", "RadioStack", "MuzoRack" etc. as plugin packages that integrate for that purpose. Of course we wouldn't be doing any more than Radio and News related stuff at this point as we've all agreed to focus on those, but this model for the bundler would allow for that future thinking possibility - whether we ever implement additional packs or not. And it would mean if someone wants the Radio stuff without the News stuff, that become easier too.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/netmix/openproducer-platform/issues/22#issuecomment-858375656, or unsubscribe https://github.com/notifications/unsubscribe-auth/AA65WO2CB7MD5QIBLTSNWODTSBQ6HANCNFSM45UWYC2A .

-- Sent from Gmail Mobile

[gusaus]

@majick777 Finally able to circle back to this as we seem to be in a bit of a holding pattern with FundOSS. Couple quick thoughts based on discussions @tonyzeoli and I have been having.

So while I do like the sound of "RadioStack" - I agree with @tonyzeoli that it really does make sense for them to have them same name. And I "get" that OpenProducer is the over-arching name and ALSO the name for the "Collective"... But given the naming conventions you've both discussed, just "OpenProducer" could still be the bundler plugin name.

I think we all agreed on this after taking another look at what Newspack does. Here's screengrabs from or DM convo that led us to the conclusion we should call the bundler and distribution (if that's the term we're using for https://github.com/netmix/openproducer-platform) the same thing.

The lingering question I think was what to call the bundler plugin (openproducer, openproducer-plugin, openproducer-platform, etc) - something we were discussing here https://github.com/netmix/openproducer-platform/issues/31

By the way (if you didn't already know), in Drupal world OpenProducer was intended to be a distribution (a project type). https://www.drupal.org/project/openproducer

One thing that threw me off was that WordPress handles this differently - I actually realized this after this back / forth with @tonyzeoli https://github.com/netmix/openproducer-platform/issues/2#issuecomment-584437766

Was also where I discovered Newspack and decided soon after to make the switch from Drupal to WordPress!

Say as a slight alternative to what we've threshed out already, upon installing OpenProducer plugin it would ask you in the installation wizard, something like "What is your intended purpose for this website?" And then you could select any combination of "Newspack", "RadioStack", "MuzoRack" etc. as plugin packages that integrate for that purpose. Of course we wouldn't be doing any more than Radio and News related stuff at this point as we've all agreed to focus on those, but this model for the bundler would allow for that future thinking possibility - whether we ever implement additional packs or not. And it would mean if someone wants the Radio stuff without the News stuff, that become easier too.

I've been wondering if something like this was possible but not sure if we've gotten around to discussing it. This sounds similar to a Drupal installation profile https://www.drupal.org/docs/distributions/creating-distributions/how-to-write-a-drupal-installation-profile

The difference is the bundler and installation profile(s) are just self-contained in the distribution. If we had actually followed through with https://www.drupal.org/project/openproducer (finding available developers in Drupal is almost impossible) we would have created multiple installation profiles (publishing, radio, etc) within the one distribution, rather than multiple distributions (openproducer-publishing, openproducer-radio, etc).

Just another interesting tidbit - for Drupal 8 (we never released anything beyond Drupal 7) we'd decided to use the Drupal equivalent of Newspack as a base https://www.drupal.org/project/thunder

Our reasoning was almost exactly the same - most of the features we needed were included in Thunder - and we didn't need to invest much in development and updates since their well funded team was doing that for us. It's extremely similar to what Automattic is doing for us now!

With all that said, I'm thinking openproducer should be the distribution/plugin name. And then if we had multiple flavors like News and Radio (or similar descriptive names) those would be separate bundler/plugins?

I'm probably not using the right terms, but I'm very down with the idea if it's possible!

[gusaus]

Here's another thing - if what @majick777 is proposing https://github.com/netmix/openproducer-platform/issues/22#issuecomment-858375656 is possible and the distribution/plugin/wordpress project was called 'openproducer', it kinda makes sense to call the project in this repo and on our collective 'OpenProducer'. What if changed the name on these without changing the urls? - https://github.com/netmix/openproducer-platform https://opencollective.com/openproducerplatform

Yes, that would make OpenProducer both open source project and the service - I think some better messaging on the service end would alleviate any confusion. That's one thing I'm planning on spending more time with next week.

Would this make sense?

[majick777]

@gusaus Well yes but not quite, in again that I see this repository ("openproducer-platform") as the "distribution package" and we would just create a new separate one for the bundler plugin (tentatively "openproducer".)

Why? Well this is just on the thought that we may want to use the platform repo for a more specific setup or purpose. For example - and I know this is not something we should get into now! - if there was more specific server-level or database-specific setups that we wanted to include in a SaaS, when setting up for a new customer on that service, it could pull straight from the distribution package that has things all setup for that to save time. Again, that is down the line, and not work we will be doing anytime soon, but as this repo already exists, I don't think it makes sense to change the slug just to put something different here when it could possibly be used for that (once that is a commercial venture it could be possibly made private for that use since the open source bundler plugin is available free.)

So if we do agree on OpenProducer for bundler plugin name (with "openproducer" slug), we could just create a new repo for that at /netmix/openproducer and go from there without having to mess with this one at this point. It makes sense that using the openproducer.org for this open source project as a whole. (and getopenproducer.com reserved for your current/our future website/SaaS offering.) If I am understanding then this is basically how you have it already, though with this clarity it may lead to what to have on those domains and how to structure them and their content to reflect this.

[gusaus]

Not suggesting changing the slug but maybe the name. mainly because openproducer platform looks a bit long on the FundOSS site. But that would mean there would be twi collectives called openproducer

So I think we’re good leaving the way things are now 😀

On Fri, Jun 11, 2021 at 7:08 PM majick777 @.***> wrote:

@gusaus https://github.com/gusaus Well yes but not quite, in again that I see this repository ("openproducer-platform") as the "distribution package" and we would just create a new separate one for the bundler plugin (tentatively "openproducer".)

Why? Well this is just on the thought that we may want to use the platform repo for a more specific setup or purpose. For example - and I know this is not something we should get into now! - if there was more specific server-level or database-specific setups that we wanted to include in a SaaS, when setting up for a new customer on that service, it could pull straight from the distribution package that has things all setup for that to save time. Again, that is down the line, and not work we will be doing anytime soon, but as this repo already exists, I don't think it makes sense to change the slug just to put something different here when it could possibly be used for that (once that is a commercial venture it could be possibly made private for that use since the open source bundler plugin is available free.)

So if we do agree on OpenProducer for bundler plugin name (with "openproducer" slug), we could just create a new repo for that at /netmix/openproducer and go from there without having to mess with this one at this point. It makes sense that using the openproducer.org for this open source project as a whole. (and getopenproducer.com reserved for your current/our future website/SaaS offering.) If I am understanding then this is basically how you have it already, though with this clarity it may lead to what to have on those domains and how to structure them and their content to reflect this.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/netmix/openproducer-platform/issues/22#issuecomment-859982284, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAA32TBYIGJSI2VEJGO5IULTSK6SJANCNFSM45UWYC2A .

-- Gus Austin https://openproducer.org/ https://twitter.com/getopenproducer https://twitter.com/gusaus