Moving ss.org/modules to separate website (addons.ss.org)?

[Ingo Schommer]

Hello everybody,

We have two really awesome GSOC ideas which have a large impact on the community as a whole:

- New module architecture around Composer

- Improve ss.org/modules (and integrate it with Composer)

We're considering using the second project to migrate the current

module/theme/widget logic on ss.org to a new website,
for architectural and organisational reasons. 

The decision is going to influence the GSOC project quite heavily,

so we need to make it fast - here's some pros/cons:

Separate website (modules.silverstripe.org):

- Pro: Sandboxed, easier for community to contribute and maintain

- Con: More integration work required (single sign on, exposing module ownership on profiles)

- Con: Needs more design/branding oversight

- Con: No search integration with http://www.silverstripe.org/search (needs opensearch)

Integrate with silverstripe.org:

- Pro: Single sign on (reused existing logins)

- Pro: Design mostly exists already

- Pro: Integrated with existing community profiles

Despite the many cons, I think the first point (easier community contributions)

makes up for all of those - and we're tending towards making it a separate website.

Its mainly a decision for GSOC and the team maintaining ss.org,

but we also want to ensure that the solution still works for its users: you! :)

Apart from potential new features, do you think a separate website will still

allow you to discover and review modules efficiently?

There's some background discussion about potential new features and project direction here:

https://groups.google.com/d/topic/silverstripe-dev/iYmT1tJlb-E/discussion

https://groups.google.com/d/topic/silverstripe-dev/IbNAQyeg5gc/discussion

Thanks

Ingo

[Will Rossiter]

Con: No search integration with http://www.silverstripe.org/search (needs opensearch)

If the source for the modules site is public I'd be happy to contribute to getting open search support working between SilverStripe.org. For those not aware, me and Ingo started on http://www.silverstripe.org/search as a base for global searching so we have a precedent on that aspect.

I think the design for silverstripe.org modules section needs a significant overhaul anyway so could be good to give the site a fresh start. We can use the global nav from pages like http://doc.silverstripe.org on the new extensions.silverstripe.org (or whatever we call it) to make it easy to switch between the sites and provide global search.

--
You received this message because you are subscribed to the Google Groups "SilverStripe Core Development" group.
To post to this group, send email to silverst...@googlegroups.com.
To unsubscribe from this group, send email to silverstripe-d...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/silverstripe-dev?hl=en.

[Jeremy Shipman]

This site was recently mentioned on the silverstripe small business
group:
http://ssmods.com/modules/ ...an effort developed by Nicolaas.

Here are some other related discussion threads on the small business
group, for those who may not be aware:

https://groups.google.com/d/topic/silverstripe-small-business/-gHJbGnxtOo/discussion

https://groups.google.com/d/topic/silverstripe-small-business/8-7BL2SvPJc/discussion

On Sun Apr 15 21:51:58 2012, Will Rossiter wrote:
>> Con: No search integration with http://www.silverstripe.org/search
>> (needs opensearch)
>
> If the source for the modules site is public I'd be happy to
> contribute to getting open search support working between

> SilverStripe.org <http://SilverStripe.org>. For those not aware, me

> and Ingo started on http://www.silverstripe.org/search as a base for
> global searching so we have a precedent on that aspect.
>

> I think the design for silverstripe.org <http://silverstripe.org>

> modules section needs a significant overhaul anyway so could be good
> to give the site a fresh start. We can use the global nav from pages
> like http://doc.silverstripe.org on the new

> extensions.silverstripe.org <http://extensions.silverstripe.org> (or

> whatever we call it) to make it easy to switch between the sites and
> provide global search.
>
>
> On 15/04/2012, at 9:39 PM, Ingo Schommer wrote:
>
>> Hello everybody,
>>
>> We have two really awesome GSOC ideas which have a large impact on
>> the community as a whole:
>> - New module architecture around Composer

>> - Improve ss.org/modules <http://ss.org/modules> (and integrate it

>> with Composer)
>>
>> We're considering using the second project to migrate the current

>> module/theme/widget logic on ss.org <http://ss.org/> to a new website,

>> for architectural and organisational reasons.
>> The decision is going to influence the GSOC project quite heavily,
>> so we need to make it fast - here's some pros/cons:
>>
>> Separate website (modules.silverstripe.org

>> <http://modules.silverstripe.org/>):

>> - Pro: Sandboxed, easier for community to contribute and maintain
>> - Con: More integration work required (single sign on, exposing
>> module ownership on profiles)
>> - Con: Needs more design/branding oversight
>> - Con: No search integration with http://www.silverstripe.org/search
>> (needs opensearch)
>>

>> Integrate with silverstripe.org <http://silverstripe.org/>:

>> - Pro: Single sign on (reused existing logins)
>> - Pro: Design mostly exists already
>> - Pro: Integrated with existing community profiles
>>
>> Despite the many cons, I think the first point (easier community
>> contributions)
>> makes up for all of those - and we're tending towards making it a
>> separate website.
>> Its mainly a decision for GSOC and the team maintaining ss.org

>> <http://ss.org/>,

>> but we also want to ensure that the solution still works for its
>> users: you! :)
>> Apart from potential new features, do you think a separate website
>> will still
>> allow you to discover and review modules efficiently?
>>
>> There's some background discussion about potential new features and
>> project direction here:
>> https://groups.google.com/d/topic/silverstripe-dev/iYmT1tJlb-E/discussion
>> https://groups.google.com/d/topic/silverstripe-dev/IbNAQyeg5gc/discussion
>>
>> Thanks
>> Ingo
>>
>> --
>> You received this message because you are subscribed to the Google
>> Groups "SilverStripe Core Development" group.
>> To post to this group, send email to
>> silverst...@googlegroups.com

>> <mailto:silverst...@googlegroups.com>.

>> To unsubscribe from this group, send email to
>> silverstripe-d...@googlegroups.com

>> <mailto:silverstripe-d...@googlegroups.com>.

[xeraa]

We're considering using the second project to migrate the current

module/theme/widget logic on ss.org to a new website,
for architectural and organisational reasons. 

The decision is going to influence the GSOC project quite heavily,

so we need to make it fast - here's some pros/cons:

I'm all for decoupling, but does it really make a big difference?

I assume the source would be publicly available in both cases and any changes would need a review by someone at ss.org (as it's something "official" under the ss.org domain). However, I know nothing about the underlying infrastructure, so I'm probably not seeing the full picture.

Cheers,

Philipp

PS: I haven't heard anything from Nicolaas about the status / outlook of his project lately and I thin the code is not publicly available at the moment. While we might be able to reuse some parts (would be great, if we could do that), the two projects are aiming for a much broader scope IMHO. Ingo already did a comparison of the "official" page and Nicolaas'.

[Sam Minnée]

We're not that keen on open sourcing the *entire* codebass of SS.org, because it would make creating a site that looks identical the path of least resistance, which would create a confusing situation for users. We could build the adding section as a module that we load into SS.org, but there's still refactoring effort there, and it makes it unclear exactly how the module ties into the rest of the site. Having a separate site for modules with an OSS codebass would make collaboration easier.

Having a structure in place for SSO would make it easier to bring other systems under a single umbrella. For example, we currently make heavy use of GitHub and Trac. On a less critical, more fun note, it would be cool to have member profiles running on a site such as SilverStripe.me, with profiles linking to the forum, addons site, GitHub, Trac, and anywhere else.

[Nicolaas Thiemen Francken - Sunny Side Up]

Hi

Thank you for the plug Jeremy. Source is publicly available here:

https://silverstripe-ecommerce.googlecode.com/svn/modules/ecommerce_software/trunk

It sits within the e-commerce framework, but can easily be dis-connected.  I am thinking about connecting it to a "favourites" model.  Where users can save their favourites.

I have been a bit overwhelmed with all the GSOC posts... There is no way I can keep up with them.

Here are the main reasons I started ssmods.com

1. it should be super easy for the developer to list their module. They should not need to update it if they dont want to. E.g. Import readme.md file for further information

2. modules should receive "tags" that are manually added so that you can search easily (e.g. http://ssmods.com/services/pre-developed-functionality/new-modules/#filter_database)

3. we should have an API so that many sites can list the same modules (e.g. http://ssmods.com/api/v1/ModuleProduct/519/)

4. the best way to evaluate a module is by seeing a demo (we would like to provide a service where modules (+themes) can be setup on a test server) 

5. ability for module developers to earn some $$ every time their module in installed (I am still trying to work out a system for this). 

Obviously ssmods.com should not be the central place for SS modules, but it can be of assistance and exchange data with it. 

Cheers

Nicolaas

[xeraa]

We're not that keen on open sourcing the *entire* codebass of SS.org, because it would make creating a site that looks identical the path of least resistance, which would create a confusing situation for users. We could build the adding section as a module that we load into SS.org, but there's still refactoring effort there, and it makes it unclear exactly how the module ties into the rest of the site. Having a separate site for modules with an OSS codebass would make collaboration easier.

I didn't assume you'd open source the entire site - only the module page project. If you're sure this is easier and the way to go, I'll fully trust you :-).

Thanks Nicolaas!

IMHO we should try to reuse as much as possible so this will come in handy.

Cheers,

Philipp