The future of GetPaid?

[Moo]

Hi,

I participated the GetPaid sprint in Budapest. There were some worries
among the participants for which I have ginve thoughts afterwards.

Many people would love to use GetPaid for creating shops, but it won't
do it.
Currently there are huge gaps within the code (payment processors,
taxes, variant items, architecture limitations) which are necessities
for a basic shop functionality. If you want to use GetPaid, be
prepared to spent countless of hours writing everything from scratch
and "fight against the framework".

Until we have a solid working shop platform I suggest not mentioning
"shop" on www.plonegetpaid.com and actually tell the people to seek
help from Python shopping products.

Also, GetPaid future does not look very bright. Since the orignal work
was sponsored, the orignal authors have not been very activate with
the community. With the current state of the code it is hard to get
anything done unless you have years of Plone experience. Most users
who would like to use or develop GetPaid don't necessarily have this.
They might try and get frustrated after couple of hours.

There is also lack of release manager or trunk maintainer. There is no
one "in control" and people may or may not commit something into
trunk. The vision and active maintenance is missing. There is no
roadmap. There is no committed maintainers. This kind of organization
may fit for small static components like most of those in Plone
collective, but it definite doesn't seem to work with GetPaid.

So, should people looking for shopping products abandon GetPaid in
favour of other solutions? There is so much good work in GetPaid, but
it is so hard to get anything out of it.

-Mikko

[Christopher Johnson]

Hi Mikko,

Thanks for sharing your notes after the conference and sprint. Certainly some of the points you mention are an accurate description of the current state of GetPaid (ie there is no product manager now), but I think your characterization of GetPaid's viable underestimates both the product and the people in the community and I wanted to respond and provide some of the information that was shared in the conference presentation as well.

One thing to clarify though about the purpose of the project - GetPaid isn't meant to attract ecommerce people to using Plone. It's meant to keep people from leaving Plone because they have ecommerce needs. This was what drove the origin of the project and I think today is still relevant. If people want only ecommerce and don't care about all the power Plone brings, there's little reason they should use GetPaid.

The architecture does have a fairly high barrier to entry for developers. In part, because it was created as a zope3 product in the very early days of zope3 products for Plone. So a python programmer with no Plone knowledge will have to ramp up on some technologies before being able to customize it. I think this can be said about Plone in general these days also.

But, that depends on how you want to customize it...there are many things that are fairly straight forward to do. If that weren't the case, we wouldn't have had such huge growth in add ons for the product and payment processors over the last year (over twice as much code overall and over twice as many payment processors). And most of the time, that's what someone implementing a site needs to do.

There are several sites that have been launched with GetPaid already. About two dozen are listed at http://www.plonegetpaid.com/why/sites-using-getpaid .  Some are just "out of the box" GetPaid and work well for the client as is, some are customized (and many of the docs about how to achieve the customizations shown are linked to in the presentation I gave at the ploneconf2009: http://snurl.com/getpaid-slides ).

Regarding people who are playing roles to maintain the product, GetPaid has gone through a period of activity and evolution, several releases. Unfortunately, I left some of this story out of the presentation in Budapest. Perrito (Horacio Duran) has managed a release (0.6.2, I believe) and Lucie at SIx Feet Up has managed releases over the 0.7 series of PloneGetPaid, and David Glick from Groundwire has been involved since ~0.8. These are all people in the Plone community who are/were involved over a period when they were using GetPaid and were working to make it better for their needs. I'm hoping that is what we are starting again as a community.

The project is now in a period where we need new people with interest in ecommerce in Plone to step up and lead in various aspects of the project. That's an invitation I extended during the presentation at the conference. There are several people interested in getting the remaining needed functionalities (downloadable files, premium content, others), and the model we took in organizing this project originally (see Social Sourcing presentation, www.ifpeople.net/solutions/social-sourcing ) was about getting people involved upfront in a round of changes. So yes, as you point out, there was an original architect who is no longer active in the project. But, of the other sponsors, supporters and contributors at the very outset of the project, about 3/4 are still involved in the project in one way or another, which gives us a solid basis of community around GetPaid. Now it's time to get the community involved in actively shaping the future again.

In doing this, I'm willing to help transfer knowledge I have about the product to those who want to take a role in the community. Also, I think it would be great to have a collaborative design process at this point, as we did originally, so the new people involved in GetPaid can shape where the product is going. I'm willing to help those involved in this also, and if needed, to raise additional funds for the buildout of features/refactoring for GetPaid.

With the knowledge of our community, we should be able to unlock the good stuff in GetPaid and make it much more accessible for those using the system.

Best wishes,
Chris

--
GetPaid for Plone: http://www.plonegetpaid.com (overview info) | http://code.google.com/p/getpaid (code and issue tracker)
You received this message because you are subscribed to the Google Groups "getpaid-dev" group.
To post to this group, send email to getpa...@googlegroups.com
To unsubscribe from this group, send email to getpaid-dev...@googlegroups.com

For more options, visit this group at
http://groups.google.com/group/getpaid-dev?hl=en?hl=en

--
Cofounder and CEO
ifPeople - Innovation for People
www.ifpeople.net
t: 678-608-3408
130 Boulevard NE, #6
Atlanta, GA 30312

[Matt Halstead]

I agree with Chris here. I would see the following would help:

- some life breathed into http://plone.org/products/getpaid/roadmap
... there are many features and core fixes that people are
contributing to, it would be useful to list these and bring them
together as proposals that could be discussed and timelined

- a set of rotating release managers, with each release manager
delegating responsibility for certain proposals in the timeline which
are coming up for release and ensuring the release goes ahead.

- it is quite difficult to get a sense of what testing is required
when a new feature or fix is added and I think this may stop a lot of
individuals contributing to the code where their local need requires
some changes. The number of combinations of getpaid packages and plone
versions is quite high (I'm including all the different payment
processors in there) and it feels like quite a large task to test
these in relation to a change that you want to make. It would be nice
to have a recipe and some kind of delegation for testing too. I would
like to at least see each payment processor having a 'current' owner
whose responsibility it is to test their processor for a given release
candidate.

One of the most difficult aspects of helping to maintain this code is
that as a developer you are seldom using it each day (unlike core
plone components and addons that you rely on for perhaps most of your
site's function). So contribution seems to be adhoc on a need to fix
something basis, which makes momentum difficult to maintain. Finding
some funding to maintain some continued part-time contribution for a
number of people (which could rotate over time) would probably help. I
don't think many people would have to contribute much per month for
the right momentum to be achieved.

cheers
Matt


On Nov 17, 7:32 am, Christopher Johnson <cjj.ifpeo...@gmail.com>
wrote:

> two dozen are listed athttp://www.plonegetpaid.com/why/sites-using-getpaid.  Some are just

> "out of the box" GetPaid and work well for the client as
> is, some are customized (and many of the docs about how to achieve the
> customizations shown are linked to in the presentation I gave at the
> ploneconf2009:http://snurl.com/getpaid-slides).
>
> Regarding people who are playing roles to maintain the product, GetPaid has
> gone through a period of activity and evolution, several releases.
> Unfortunately, I left some of this story out of the presentation in
> Budapest. Perrito (Horacio Duran) has managed a release (0.6.2, I believe)
> and Lucie at SIx Feet Up has managed releases over the 0.7 series of
> PloneGetPaid, and David Glick from Groundwire has been involved since ~0.8.
> These are all people in the Plone community who are/were involved over a
> period when they were using GetPaid and were working to make it better for
> their needs. I'm hoping that is what we are starting again as a community.
>
> The project is now in a period where we need new people with interest in
> ecommerce in Plone to step up and lead in various aspects of the project.
> That's an invitation I extended during the presentation at the conference.
> There are several people interested in getting the remaining needed
> functionalities (downloadable files, premium content, others), and the model
> we took in organizing this project originally (see Social Sourcing

> presentation,www.ifpeople.net/solutions/social-sourcing) was about getting

> > "shop" onwww.plonegetpaid.comand actually tell the people to seek

> > help from Python shopping products.
>
> > Also, GetPaid future does not look very bright. Since the orignal work
> > was sponsored, the orignal authors have not been very activate with
> > the community. With the current state of the code it is hard to get
> > anything done unless you have years of Plone experience. Most users
> > who would like to use or develop GetPaid don't necessarily have this.
> > They might try and get frustrated after couple of hours.
>
> > There is also lack of release manager or trunk maintainer. There is no
> > one "in control" and people may or may not commit something into
> > trunk. The vision and active maintenance is missing. There is no
> > roadmap. There is no committed maintainers. This kind of organization
> > may fit for small static components like most of those in Plone
> > collective, but it definite doesn't seem to work with GetPaid.
>
> > So, should people looking for shopping products abandon GetPaid in
> > favour of other solutions? There is so much good work in GetPaid, but
> > it is so hard to get anything out of it.
>
> > -Mikko
>
> > --
> > GetPaid for Plone:http://www.plonegetpaid.com(overview info) |

> >http://code.google.com/p/getpaid(code and issue tracker)

> > You received this message because you are subscribed to the Google Groups
> > "getpaid-dev" group.
> > To post to this group, send email to getpa...@googlegroups.com
> > To unsubscribe from this group, send email to

> > getpaid-dev...@googlegroups.com<getpaid-dev%2Bunsu...@googlegroups.com>

[Mikko Ohtamaa]

Hi,

Thanks for sharing your notes after the conference and sprint. Certainly some of the points you mention are an accurate description of the current state of GetPaid (ie there is no product manager now), but I think your characterization of GetPaid's viable underestimates both the product and the people in the community and I wanted to respond and provide some of the information that was shared in the conference presentation as well.

Thanks for very good response Chris. I hope I was not over-critical with some of my points, I must some I love getpaid very much though feeling the frustration now and then, like many of us do. It's almost there that you could use it for Plone commercing needs, but it gives some problems which would be solved if you used external shopping system. I was hoping that my email would inspire some discussion so people, even ones who didn't go to conference, could see that the train is still going :)

 

There are several sites that have been launched with GetPaid already. About two dozen are listed at http://www.plonegetpaid.com/why/sites-using-getpaid .  Some are just "out of the box" GetPaid and work well for the client as is, some are customized (and many of the docs about how to achieve the customizations shown are linked to in the presentation I gave at the ploneconf2009: http://snurl.com/getpaid-slides ). 

I think the barrier comes when you need to have some "deeper" customizations. Like having a new field on Order. You basically need to go to hand-edit getpaid.core or override various, various, adapters and templates. Which makes it difficult as it is not very clear how things are connected. Getpaid architecture, nice as it is, tries very hard to keep "architecture" (getpaid.core) and "implementation" (Products.PloneGetPaid) separate from each other. For example, payment processor contain both architectural and UI drop ins. The problem comes with latter when people create plug-ins which need to use overrides.zcml to get things done. However these problems are just technical, and they can be solved when community knows what they are aiming at and have time do the work. This issue has been already discussed partially with's Brandon's work on payment processors.

Regarding people who are playing roles to maintain the product, GetPaid has gone through a period of activity and evolution, several releases. Unfortunately, I left some of this story out of the presentation in Budapest. Perrito (Horacio Duran) has managed a release (0.6.2, I believe) and Lucie at SIx Feet Up has managed releases over the 0.7 series of PloneGetPaid, and David Glick from Groundwire has been involved since ~0.8. These are all people in the Plone community who are/were involved over a period when they were using GetPaid and were working to make it better for their needs. I'm hoping that is what we are starting again as a community.

Great :) The problem is that no one really knows when to commit trunk. Lots of patches end up being in the bug reports and email attachment (like the late issues with inter-database references), when there is no a single point of contact who would help to maintain the trunk. As already discussed, some nice ideas come up.

>The project is now in a period where we need new people with interest in ecommerce in Plone to step up and lead in various aspects of the project. That's an invitation I extended during the presentation at the conference. There are >several people interested in getting the remaining needed functionalities (downloadable files, premium content, others), and the model we took in organizing this project originally (see Social Sourcing presentation, >www.ifpeople.net/solutions/social-sourcing ) was about getting people involved upfront in a round of changes. So yes, as you point out, there was an original architect who is no longer active in the project. But, of the other sponsors, >supporters and contributors at the very outset of the project, about 3/4 are still involved in the project in one way or another, which gives us a solid basis of community around GetPaid. Now it's time to get the community involved in >actively shaping the future again. 

Here we are!

Cheers,

 Mikko