Hi Chris,
I would say that we are even currently in nearly the state that I would
expect as an outcome as an official outcome of this proposal.
We currently have only very few resources to work on the CA. So it is
already stuck in a status where it is nearly unusable for newcomers. And
even experienced developers do not know recent hardware where it is
working on.
Benjamin tried to create a CA with a cheap recent computer that we
bought in a computer store close to campus last week. Ubuntu 10.04 does
not work on this machine anymore (like on recent Dell models). So we
switched to 12.04. The we needed to find a capture card. Again our old
reliable Hauppauge PVR 150 are no longer available and even BT878 cards
are not easy to get these days, so he decided to use an Hauppauge HVR
card that works but has some downsides.
I guess that Waldemar and I would have managed to get this setup running
with some manual configuration. But even Benjamin as an experience
user/dev of Matterhorn failed and decided to use Galicaster instead -
with some minor problems too, but at least this worked.
In general the current CA works well for USASK and for UOS as we have
people who know these devices very good and we have old hardware that is
well know to work with the reference CA. But what do you tell adopters
that ask you for some support?
You suggested to get rid of other Matterhorn components, like the engage
player too. I have no problem with this. If the majority of the
community starts to use the paella player for example and we don't have
the resources to continue the development of the reference engage
player, why shouldn't we decide to switch the default player. But at the
moment I am willing to put some ressources in the refactoring of the
player. And it seemed to me that some other institutions would be
willing to do this although.
I have not noticed that enough institutions would be willing to invest
their money or developers in the reference CA to continue the
development. If I am wrong these institutions should speak up now!
Jaime and Tobias raised some interesting questions about remote
administration, configuration and updates for the CAs, if an
institution would really deploy hundrets of them. If we come up with new
APIs and protocolls for this. Who will implement this for the reference CA?
As we at UOS are seriously investigating other options than the
reference CA too, we don't see the need to invest more of our
development resources into the reference CA and would focus on other
parts of Matterhorn.
I see the soup to nuts argument. But I am not sure is this really is
that important for a possible adopter. I would expect that that a good
installation an usage experience is more important. And from our support
for other universities here in germany I would say that with the CentOS
repo [1] we have an acceptable experience for the core. But
installation, configuration, usage and monitoring of the CA are still
pain points - especially for adopters.
Rüdiger
[1]
http://opencast.jira.com/wiki/display/MHTRUNK/Binary+Installation+from+Repo
Am 06.02.2013 02:28, schrieb Christopher Brooks:
Hi Olaf,
Keep in mind that we're not planning on deleting the CA code. Just
removing the install scripts and explicit support for various
hardware bits. There's nothing keeping adopters from using it, the
hardware support will still be there. We just won't be testing
against any hardware.
Also, I wonder whether you would consider Galicaster a solution that
still allows us to claim that soup-to-nuts approach. The software is
OS (ignoring the licence issue here for a moment), Teltek supporting
its further development and it's not bound to HW Teltek is selling,
at least I think I remember Stuart saying he's running it on his own
cobbled device.
What Greg has written, "...removing the install scripts and explicit
support for various hardware bits..." is very different from what I
perceived in the #proposal from "...bit we will not really maintain the
code in the future so that it will be outdated in the near future..."
Regardless though, I don't support the notion that Matterhorn should not
have capture agent software and should rely on other systems alone. To
me, the benefit of Matterhorn was getting rid of the home built systems
we had individually, and coming together to build an open,
community-maintained product that could scale. I think involving other
systems, like vendor products, is important to creating a viable
piece of software, but I don't think relying on a vendor for a specific
portion of the tool chain is good.
Also, I don't know anything about the Galicaster system except what
I've read on the website and on this mailing list. Undoubtedly it is
an excellent product, but to throw away robust community-developed code
and instead tell adopters to go to this vendor for the solution is not
something I'm comfortable with.
Yes, that was my impression too. I think we've seen what a closer
alignment with certain vendors can lead to when their support isn't
there and the price policy is erratic, but I think if one could run
Galicaster SW on your own device, wouldn't that be agnostic enough?
Why don't we just drop our player and core and instead point people
towards the Kaltura community release (it's open source)? Open source
software isn't just a set of widgets we can replace, it's about a
community that people can participate in. How many different higher
education institutions have commit access to Galicaster code? How can I
contribute back new developments we make to the broader community, and
get their contributions in return? How can I contribute patches to
bugs, and fix problems when they arise instead of buying a support
contract? The answer is you can't -- it's not a community source
project.
This doesn't have to detract from all the wonderful things that
Galicaster is (free, open source, well supported, python, great
testimonials, etc.). But changing the docs to say "Go download
Galicaster" is cutting away a portion of our product and saying we're
not interested as a community in lecture capture, just media processing
and playback. And I don't think that's true, and I don't see why that
is necessary.
Chris
--
________________________________________________
Rüdiger Rolf, M.A.
Universität Osnabrück - Zentrum virtUOS
Heger-Tor-Wall 12, 49069 Osnabrück
Telefon: (0541) 969-6511 - Fax: (0541) 969-16511
E-Mail: rr...@uni-osnabrueck.de
Internet: www.virtuos.uni-osnabrueck.de
_______________________________________________
Matterhorn mailing list
Matterhorn@opencastproject.org
http://lists.opencastproject.org/mailman/listinfo/matterhorn
To unsubscribe please email
matterhorn-unsubscr...@opencastproject.org
_______________________________________________
