Re: Hosting a demo instance of uPortal-start on the web
How much of the value proposition could be realized by making
$ git clone https://github.com/uPortal-project/uportal-demo-via-docker.git
$ cd uportal-demo-via-docker $ docker up
I'm thinking about
+ Avoiding the hard dollars expense of the uPortal project running a server
+ Avoiding the operational commitments of the uPortal project running a server
but maybe more importantly, thinking about what posture and next steps this is trying to encourage.
Getting something running locally gets a would-be adopter closer to messing with it, which gets closer to active participation and contribution, which is what I see the biggest gains for the uPortal project in drawing people and institutions in.
Is a public demo something to encourage a commercial vendor (hi, Unicon!) to do? There's a bigger play than just the demo site existing, after all -- it's also having someone available to walk through it, answer questions, a contact for next steps -- and yes, to *sell* the potential "customer" on pivoting from messing with the hosted demo to seriously considering a local implementation. A vendor with sales professionals and pitching ways to convert money into local uPortal implementations might be in the best position to provide the full hosted demo uPortal service.
PS: One thing I'm working through here that's making me less excited about spending hard dollars: I'm mourning the vision of getting to a big enough recurring uPortal sustaining subscription revenue to sustainably fund an IT professional to shepherd uPortal full time, ala the last sentence of the 2018 uPortal project report.
On Wednesday, May 1, 2019 at 1:00:45 PM UTC-5, Lauren Anderson wrote:
I think it would be helpful to have a running demo of uPortal-start on the web to show off the features of uPortal and allow new customers to explore it. We could use some of the uPortal subscription budget
to fund this (hopefully, cheaply). I volunteered to figure out how much it would cost running in Amazon Web Services, since that’s how BYU is deploying it and I’m familiar with it. If anyone has suggestions for other ways to do this, please respond.
Suggested capability (based on how we’re doing it at BYU):
Automatic build from latest code in GitHub (CodePipeline), or a branch or tag derived from the most recent stable release
Nightly refresh to wipe out user customizations made while playing with it
A way to display new content being developed by, for example, the uPortal-contrib project
If we created a branch that included a CAS, Shibboleth or other login that allowed users to log in with their Google, Facebook or other credentials via OAuth2, that might be helpful rather than having to use
just the default users.