Pro-Modules - where is PW heading?

[pideluxe]

In his latest blog post, Ryan annouces his works on the ProDraft-module for handling publishing workflows. While this is really great news, there is, at least in my opinion, the drawback that this module is a Pro-module. I really appreciate the tons of work Ryan puts into PW and see the need for getting some money back not being able to do work for some clients. I also like the idea of the Pro-modules, where advanced functions not needed by anybody is sold at a moderate price, i myself have bought some Pro-modules already. 

But such fundamental functionality like draft-versioning or defining a workflow for publishing should be in the core and made open source. I would like to raise a discussion about this, how it could be solved or what other developers think. All other major open source CMS have versioning integrated, so this a field where pw lacks behind and the chance with making that in core would open more opportunities for attracting more people using PW. But then getting this functionality only by paying a decent amount could draw them immediately back without getting the beauty of PW:

Some solutions to solve this that cross my mind:

• Sponsoring: Already Avoine has sponsored some other modules being developed by Ryan, so maybe they or other companies that need drafting could stepin.
• Crowd-Sponsoring: If there is not one company or individual taking over the sponsoring, why not community fund this like a kickstarter-project? I think, most of us could spent at least the amount the Pro-module would cost or even more to make it open for public.
• Making only support Pro: Now all the Pro-modules get higher priority support by Ryan. Not only being the only person doing this, but maybe the only individual capable of supporting all the modules at moment, this can become a bottleneck in the future. Being open source, others can work on adding functionality and bug tracking and Ryan could concentrate on supporting. Other CMS are already doing this more or less (i.e. Acquia for Drupal).

What do you think, should fundamental functionalities stay available in core for all or only being available as Pro?

[apeisa]

Having used ProcessWire for 5 years and in 50 projects (or so) without drafts, I don't think it's fundamental functionality by any means. Very rarely requested and much more rarely actually needed.

For Avoine, I don't see big need for drafts, so having it as pro module is much better for us than sponsoring. 

[LostKobrakai]

I think the problem with drafts really is what apeisa is saying: It's most of the time an overused and therefore overrated feature. As long as you're not catering to the big corporations where content is really managed by a dozen or more people it's arguable if it's really needed. Sometimes having a live and a draft-state would be nice for already published content, but everything else is not a widespread requirement. I think about multiple drafts, draft comparison or diffs and enhanced permission handling. 

But the other argument about the competitors is true. All of them handle drafts by default without even thinking much about it. It's always handled like kind of a must have feature.

[Pete]

What the guys said above - I hadn't thought about it like that and was going to suggest something else, but the more I think about my own requirements draft pages would only have been used in less than 10% of projects I think, and even then they would warrant the price tag so not an issue really and it shouldn't be core. The only draft I need most of the time is as I'm writing something before it's published, so the unpublished state does that for me.

This does come up from time to time with new pro modules (pretty sure I remember a similar conversation way back when FormBuilder or something was released) but there's usually a good answer like the guys have made above.

I prefer that everyone who has paid for Pro Modules gets the benefit of everyone else's questions and answers in the relevant support forums. If the modules were free to all, other community members would undoubtedly help out non-paying folks in the forums which is fine, but given that there are a lot of people here generous with their time and knowledge, folks might not need paid support or see the need to buy that option so it would be a bit of a gamble.

Having said that, some aspects would be nice in core, but not to the extent as in this module. But someone could easily build a more basic module for drafts - how do you think the Dev Directory works when you post updated content? (It actually clones the current entry, you edit the clone, then when approved it's copied over the original - a very rudimentary draft system built in a short time using just a few API commands in a small module).

[pwired]

All other major open source CMS have versioning integrated, so this a field where pw lacks behind and the chance with making that in core would open more opportunities for attracting more people using PW.

Processwire is not like "all other major open source CMS", so are you sure about that ?

To attract more people it certainly does not need cranking up it's core, but instead it

needs more marketing.

[WillyC]

this.look like a repleye to questiones here

http://processwire.com/blog/posts/processwire-2.6.13-and-a-preview-of-prodrafts/#Comment11880

allso pw all ready having sweet versionings frm weekly.pw.teppo

http://modules.processwire.com/modules/version-control/

i make draftas this like

1.installs processPageclone frm core

2.clicking copy.on page in.tree { page u want.draft of }

4.edit.edit.edit { keep unpublishas }

4.get mom to edit.fix.edit blahblahblah shutup mom

5.ready to publishas ? trash.originalas page

7.rename clones page and clicking publishas

edit

8.ok mabe i will.try prodraft

[Pete]

Good spot on that first link WillyC - didn't realise this had already come up so recently.

[Beluga]

this.look like a repleye to questiones here

http://processwire.com/blog/posts/processwire-2.6.13-and-a-preview-of-prodrafts/#Comment11880

The ideal situation would be that client/consultation work would largely go towards the core. The pro modules make it seem like the model of not selling intellectual property is not fully trusted or that it is used as a marketing gimmick.

Open source as a business model can, of course, be tricky to nail. Sometimes, though, even pre-alpha projects get enough consultancy work to keep an entire team busy.

These days I tend to think that in open source projects, the community itself can be seen as money, an energy source - tapped or left untapped. If PW had a different governance model, we could have self-organized marketing, infra & design teams and Ryan wouldn't have to lift a finger to fulfill those duties.

Open source can have a weird effect on people. In a way, I have paid tens of thousands of euros to LibreOffice in the past year (ctrl-f my nick). That would buy a lot of pro modules.

[Pete]

The ideal situation would be that client/consultation work would largely go towards the core.

What a client might pay him to do could be quite bespoke though, more so than a drafts module, so you wouldn't want really niche stuff going into the core anyway. Plus client work doesn't necessarily result in new modules or core changes at all as they would theoretically usually just be normal sites using existing modules, but still pay the bills.

Pro modules seem to slot somewhere in between client work and core. Core is something that a lot/most people would use reasonably regularly, Pro modules are useful in certain scenarios and usually of interest to a lot less people.

I think ProcessWire does definitely need some further structure in future in terms of marketing folks etc, but I'm not sure how that sort of thing even gets off the ground in other projects. All suggestions welcome, but probably in another topic.

[bcartier]

Having some experience with ExpressionEngine, Craft CMS, Drupal, WordPress and (luckily) ProcessWire, I find Ryan's approach to ProModules to be a smart and effective solution. With product exposure and attention comes a market. That market can be 3rd party commercial modules, or first-party modules.

Personally, I'd much prefer a first-party module for something at tightly integrated as Drafts. I think this is an evolutionary step for ProcessWire, and a positive one. If a project requires the workflow or functionality that ProDrafts offers, I think the small price is beyond reasonable. If you have a few publishers, and this module saves them a few minutes /day, it's paid for itself pretty quickly.  

I hope Ryan continues on this course. I don't see it detracting from the core product at all - in fact the opposite. As more Pro modules have been released, the pace of core development has spiked. All-in-all a good thing in my opinion. Sponsored development is a great contribution too (thanks Apeisa and Avoine!), but Pro Modules are also a great way to push PW forward.

[Beluga]

What a client might pay him to do could be quite bespoke though, more so than a drafts module, so you wouldn't want really niche stuff going into the core anyway. Plus client work doesn't necessarily result in new modules or core changes at all as they would theoretically usually just be normal sites using existing modules, but still pay the bills.

Pro modules seem to slot somewhere in between client work and core. Core is something that a lot/most people would use reasonably regularly, Pro modules are useful in certain scenarios and usually of interest to a lot less people.

I think ProcessWire does definitely need some further structure in future in terms of marketing folks etc, but I'm not sure how that sort of thing even gets off the ground in other projects. All suggestions welcome, but probably in another topic.

Yep, I thought I worded that a little unclearly. I didn't mean to express an opinion that drafts should be a core module

Re: team forming in open source projects - it does seem to often require years of history and dedication from power users. If we look at LibreOffice, it forked from a company-governed project to a foundation-governed one. There is a lot of paperwork involved in running the foundation and the president is mostly preoccupied with that stuff from what I know.

The foundation had been chugging along for 4 years before I joined the QA team. I don't have a clear picture about the historical amount of effort in organizing the teams, only that it was very easy for me to walk in and start contributing. I also slid into helping the design & infra teams and before I knew it I was the official Etherpad guy

Important elements in getting remote team members to work efficiently are effective web-based collaboration tools.

[pideluxe]

Thanks for all your thoughts about this (especially the beardman). Maybe my first post did not express what i wanted to say. Draft and versioning isn't a must for being in core, but a free available module with reduced functionality would be good. Sure, you could build that by yourself and PW makes it easy, but for one coming from an other CMS this is not the best answer for convincing to switch to PW.

I agree that versioning is not needed in every situation, but a workflow or being able to preview a pagewihtout publishing are often demanded features also here in the forum. Everyone who is evaluating PW for using it for a larger scale website or working in a team asks for this.So telling them: "yes, it's available, but only if you pay something" (regardless how cheap it is), may they move along looking for others.

It comes down to the question: what is the fundamental functionality a free CMS should offer. And here are the opinions different from one to another, so Ryan as the leader is settling the path where PW is heading.

[adrian]

Three free modules that might be useful (to varying degrees) for your request to be able to preview changes:

http://modules.processwire.com/modules/process-page-draft/

http://modules.processwire.com/modules/process-preview/

http://modules.processwire.com/modules/process-textarea-preview/

[teppo]

It comes down to the question: what is the fundamental functionality a free CMS should offer. And here are the opinions different from one to another, so Ryan as the leader is settling the path where PW is heading.

I realise that you kind of got your answer already, but just wanted to add some thoughts to the topic

First of all, we've discussed the "what should be in the core" topic a few times, and the conclusion has so far been something along the lines of "features that most sites require". For most sites the published/unpublished separation is more than enough, and a feature like drafts could actually be even harmful (an added complication).

ProcessWire, as it is right now, does most of what any regular site could require, and more. In fact I'd be tempted to argue that in the future we should trim down current distribution, not add to it, unless someone can point out a real need that still hasn't been answered. What Ryan has been doing with the AJAX inputfield updates, selector updates, etc. is enhancing existing features, and in my opinion that should remain the main area of focus in the near future.

Anything that isn't in the core can be realised in the form of modules, and if those modules are commercial, that's (again in my opinion) fine. ProcessWire has a viable module ecosystem, and anyone can create and publish commercial modules, if they so choose; in other words, this isn't a right reserved for Ryan alone. Of course I hope that module authors choose to open source their code and provide it for free, but I can't force that decision on anyone.. and neither can anyone else

All that being said, the way this works should be communicated clearly and visibly; what goes to core and why.

Years ago I looked into Concrete5. Back then multi-language support was only available as a commercial addition, and my first reaction was literally "what a greedy bunch they must be, asking money for what should be a core feature". Thinking about it now, I probably just didn't understand their target audience and the reasoning behind this particular decision. I sincerely hope that as few people as possible take a look at ProcessWire, see Drafts or FormBuilder or ProCache, and think that "those ProcessWire developers must be a greedy bunch to take money for obvious core features!"

[pwired]

enhancing existing features, and in my opinion that should remain the main area of focus in the near future.

Anything that isn't in the core can be realised in the form of modules

Yes, can not agree more with that. Your post summed it up very well. I hope Processwire will never take

the road of a washing powder to stay in the picture: "This Month we have added feature xyz and now you

are able to do abc like never before"

Let's never forget why so many people (e.g. from modx) migrated to Processwire:

No typical, no shine, no show or fancy but raw power !

Sometimes I have my doubts if the core of Processwire will stay like this because if you look around in the world,

the temptations of becoming part of the status quo, buzz or popularity, is immense.

I hope Ryan and his team will never fall for it.

The focus should not be the core but marketing Processwire.

[jasonhuck]

IMO, ListerPro is the only pro module which provides such absolutely critical functionality that the core CMS is incomplete without it.

[LostKobrakai]

What part do you consider critical about ListerPro, that the core Lister doesn't give you? I've sites running, which do work without any lister as well as ones, where Lister(Pro) wasn't flexible enough so I had to create custom modules to list things and add custom overviews and functionality. Therefore I don't see whats so critical about it.

[Pete]

I've never really used Lister beyond its implementation on the Users page in the admin to be honest.

But then there's always one who'll have the opposite view

[jasonhuck]

What's critical about Lister Pro?

The ability to easily save a customized lister, perform bulk actions on results, and have convenient, end-user access to tabular views of large content types that are too cumbersome to manage from within the tree control. This is standard functionality in any CMS worth using, and essential for the vast majority of sites I've built over the last 20 years or so.

It's a bit silly, IMO, that you can't do these things with the built-in lister. It feels intentionally crippled solely for the sake of selling the commercial component, a perception we want to avoid. I wouldn't build anything more than the most basic, trivial processwire-powered site without Lister Pro, whereas I could easily do without the other pro modules. I (sometimes) use Form Builder out of convenience, but Lister Pro out of necessity.

Mind you, I'm not complaining about the cost, at all. It's entirely reasonable and I'm happy to support development. But if we're talking about the road map for the core, open source project, I most definitely view Lister Pro as essential functionality that absolutely should be part of it.

I am intrigued by the idea of "graduating" pro modules to core modules via some process that combines hitting some financial goal with enough general community interest in having specific functionality available in the core.

Just my two cents.

[LostKobrakai]

Both customized listers and bulk actions are available to you without ListerPro. Just have a look at the core ProcessUsers and PageActions modules. ListerPro just provides the "more than easy to setup" interface for those things. But maybe the basic "set up a new Lister" functionality could really be move to the core Lister in the future, as the Pro Version seems to be getting other unique selling points.

[jasonhuck]

Please elaborate. Are you saying there's a way, within the admin UI, to create multiple, permanent, customized listers? If so, I've missed it somehow.

I realize you can create a custom module (even if it's mostly copy/paste from an existing one) for each lister needed, but IMO it's such a common, fundamental need, the core admin UI ought to be taking care of it for you.

[mr-fan]

For listing pages or subpages, import, export and editing stuff

https://processwire.com/talk/topic/6102-batch-child-editor/

is a very heavy tool that is released as opensource...as an little alternative.

But i agree i install Lister Pro on every Page and have a very easy setup of listing things for my users...but i've no problem if it stays comecial....since i love to support my CMS/CMF of choice and his developer ryan with this small contribution.

I know you wrote the same - but it shouldn't integrate in the core - since PW is more intended as a (very powerful) toolbox than a ready to use CMS.

So buy Lister Pro is like spending the development some money AND get two things for that contribution 1) good feeling 2) really good module

best regards with good feelings mr-fan

[LostKobrakai]

ListerPro just provides the "more than easy to setup" interface for those things.

Therefore, nope there's no UI, but it's certainly possible. Especially the people, who are in the need to setup multiple different listers are most likely able to setup these via the modules code as well.

[adrian]

For listing pages or subpages, import, export and editing stuff

https://processwire.com/talk/topic/6102-batch-child-editor/

is a very heavy tool that is released as opensource...as an little alternative.

Thanks for the advertisement @mr-fan.

Just to let you guys know here, the dev version of this module actually has a new "Lister" mode that works without ListerPro and allows you to embed a customized Lister into the editing interface for any page on your site.

[mr-fan]

No ad - just the truth

You know that on the import/export topic i was involved in testing - BCE works much better than CSV-Export or Lister-Export.

(I'm little behindhand with my german translation for the dev... ..summertime is always a appointment mess)