paroneayea

You can host media files on Wordpress or Drupal, but the goal here is to build an application that's very focused and tailored user-interface wise to media. Furthermore, Wordpress and Drupal alone might not very easily handle some of the extra tooling that MediaGoblin does: if you upload a video, that video needs to be transcoded; we have task queueing and infrastructure so that these things can happen in the background without you just sitting there and your browser timing out.

As for how federation will work, we may enable a plugin called "diskgobbler" or something that might dowload files, but no, by default, MediaGoblin will not mirror all files from the other sites it is federating with. :) Instead, the goal is to keep the social side of things alive: you can create galleries that have entries that span multiple sites, favoriting a piece of media can happen across instances, you can subscribe to things a-la YouTube channels. That's what we mean as in terms of what we aim for by federation.

Hope that answered a bit!

Keep in mind that MediaGoblin is mostly a community project. I'm the only paid fulltime employee at present (and that's thanks to the crowdfunding campaign through the FSF). It's a HUGE project, and there's not a lot of time to go around. So yes, if code's moving by a million miles a minute in the codebase and my job is to make sure that contributors are doing well and that the software is great, that might mean that the homepage might suffer... I can only do so many jobs at once.

And in any case, it's not just a "oh, we tossed an intern at this"; in this case, the person who's working on this is a community member and intern, and is doing work based on a detailed analysis based on another community member's work overviewing all our current messaging: http://lists.mediagoblin.org/pipermail/devel/2013-July/00061...

So it's not just a matter of, "oh get an intern and toss them at it"!

But hey, if you're bothered by the fact that we're a community project with not a lot of full time resources, you can donate and help us pay for more people to come on as dedicated resources! The crowdfunding campaign we ran through the FSF last year is over, but the donation link still works: http://mediagoblin.org/pages/campaign.html

Or, feel free to help us out yourself! http://mediagoblin.org/pages/join.html

Heya! So, we sometimes get comments about the branding choice of "goblins"... our goblins are actually not evil, though I agree that a lot of $STANDARD_FANTASY they're used as evil characters. Our goblins are more "build spaceships, be cute, and be awesome" goblins like http://mediagoblin.org/news/mediagoblin-0.3.2-goblinverse.ht...

Curiously we've gotten a number of concerns about maybe the branding will push people away by thinking that the goblins are evil or scary or will frighten children, but we've never actually had anyone tell us that it actually invoked that reaction in them, just that they're concerned about it. And a lot of people seem to really like the goblins.

We do have a light theme called "airy"; there's some debate about whether that theme should be default. The choice of a dark theme isn't to invoke something dungeon'y, it's to put spotlight on the media, making the media the "light" of the scene. But anyway, maybe at some point we will switch over to airy by default... we'll see what the future brings.

Thanks for your comment!

We're working on federation support, and I think that would be pretty fair to call decentralized?

Decentralized can have various definitions; GNUNet is definitely one definition, but you might consider that the web itself is supposed to be decentralized and is designed to be able to be that way, but is moving away from that as more and more of the web is being replaced by megasites like YouTube, Flickr, Tumblr. So, MediaGoblin is one attempt to take back the web in that respect.

Heya! Well, our architecture is very Flask-like, but yes it does not use Flask. There's kind of "historical reasons" for this; at the time that I started MediaGoblin Flask was fairly new, and we started out using MongoDB (so we couldn't make use of some of the nicer Django features anyway). I also really strongly prefer Jinja2 templates over Django's because of the ability to pass in arguments to functions, so eventually Django didn't make sense. But the real root of it though is that it's not actually as much work as people think to hook together a WSGI application that uses the libraries you already know you want... not really that much harder than using Flask anyway! http://docs.webob.org/en/latest/do-it-yourself.html is a good read in that vein.

Will MediaGoblin stick with its own direction, or move over to using Django or become a Flask app? It kind of depends... at the moment, things seem to be running well, and aside for waiting for some of our libraries to catch up to Python 3, we don't seem very hampered by it, and we're also very nimble... changing core parts of MediaGoblin to fit our needs is presently very easy. It also might be interesting to see what happens if eventually we end up adopting some XUDD technologies: https://xudd.readthedocs.org/en/latest/ but admittedly that's a ways out (though MediaGoblin already can run on XUDD, as of yesterday ;)) if that will happen at all.

Sorry, kind of a rambly response! Hope it was interesting.

Definitely! We have a lead graphic designer and nearly 50 programmers. As you can imagine that graphic designer is overstretched. Do you know any graphic designers who are interested in helping make MediaGoblin nicer? Point them our way, we'd love to talk to them! http://mediagoblin.org/pages/join.html

It's a legitimate complaint that syadmin'ing all these services is a lot of work, but I think that's actually an argument for working to make deployment of services such as MediaGoblin easier. Right now deploying web applications is hard... if we could get things at least to the point of deploying and maintaining systems are "as easy" (note the quotes) as "apt-get install" and "apt-get upgrade" then we'd be in a much better state. But there's a lot of work happening right now towards abstracting deployment; I think if we can turn some of that effort towards generalizing deployment recipies for everyone (not just people running big clusters of servers) we could make big improvement here. Projects like JuJu and OpenShift are probably the right directions, but admittedly I haven't had enough time to spend playing with them.

Heya! So, it's hard to know precisely re: 1.0, but I'm anticipating approximately towards the end of the year. Federation is the big thing we're still waiting on until we consider ourselves 1.0-worthy. Probably we could have tagged ourselves 1.0 a while ago and considered federation 2.0, but federation is at the root of a lot of our goals, so...

Anyway, once all our summer projects wrap up, I think we'll have reached 1.0-worthiness, however there's a lot of code being developed right now, and I can't promise how long it'll take for it to hit the "quality approval for merge" state.

We've had theming for a while, since 0.3.1! http://mediagoblin.org/news/mediagoblin-0.3.1-a-whole-new-lo...

Read the documentation for details on that, but you can already enable a light "airy" theme if you prefer.

PS: If you're a python developer and interested in federation, you may be interested in checking out our super-awesome-contributor Jessica Tallon's "PyPump" library, which integrates with the Pump API: https://github.com/xray7224/PyPump

I know she wants more users and feedback! Pump API integration is on the way, but in the meanwhile, there's a project that's already using it if you want to try out the API: http://pump.io/

Thanks for the excellent questions! Hope that rambly response was helpful :)

Thanks for linking to those. The tour page, sadly, is pretty out of date... the screenshots they show don't reflect reality! Things look a lot nicer now I think.

See also the video from the campaign page, which describes things better than the actual site: http://mediagoblin.org/pages/campaign.html

Unfortunately the site is in bad need of updating; there's so much going on in the codebase right now that it's been hard to prioritize. Luckily we now have an intern who is going to be taking on that work!

And yes, independent instances will be able to talk to each other soon. We have an Outreach Program for Women participant actively working on federation via the Pump API! https://github.com/e14n/pump.io/blob/master/API.md

That's not all that's going on alone, but you can get some sense of what else is happening by checking out: http://mediagoblin.org/news/summer-of-awesome.html

Hi! Lead developer of MediaGoblin here.

I agree, the frontpage of mediagoblin.org can use some improvement. We're working on that. If you want a fast summary of things, you can still watch the video from the crowdfunding campaign we ran last year with the FSF (hell, you can still donate too!). http://mediagoblin.org/pages/campaign.html

We also have an intern helping us clean up the homepage. Things should be getting clearer soon, I think. I agree that http://mediagoblin.org/ could use some improvement.

In the meanwhile, if you're wondering what it offers, right now it already supports nice photo, video, audio, document (pdf.js!), and even 3d model support. It's written in Python, so it's easy to get hacking on. We have a lot more exciting things on the way too, most noticably federation; we currently have someone working full time on adding federation via the Pump API: https://github.com/e14n/pump.io/blob/master/API.md

This will make it so that even though there's a bunch of separate MediaGoblin instances out there that you should be able to have a lot more of the same social features of other media hosting sites as if they're in the same place.

I'm happy to answer questions if anyone has any!

Yeah, I'm also surprised to see people so upset about the idea of the feature mostly for the argument that it doesn't presently exist. As for the compile-time-extension, my main concern with that as a free software project is that we try to play nice with distro packaging and requiring users to compile their own sqlite would be setting them up for a bit of pain. But I suspect it doesn't matter: if the feature was coded with the aim of pushing it upstream, I'm suspecting there's a good chance upstream would accept it if of good quality.

Then again, I'm not upstream. :)

Thanks for that correction. I updated the post.

Yep, and I said in the article that I'd be happy to pay for adding other ALTER TABLE methods... if someone ran a funding campaign, I'd donate quite a bit of money. I still suspect that if such a campagign was run, we'd see a good set of money come in from the community for it.

The problem though is that Alembic doesn't want to engineer itself around implementing the tooling because it's so painful (and the author of that tool is himself asking for this kind of alter table support) and sqlalchemy-migrate breaks all the time. And sqlalchemy-migrate breaks all the time, and when I used South and django-migrations (granted, that was years ago), those also broke all the time too. The external migrations path isn't working.

Thanks for that helpful reply! Interesting to see that what I wrote out isn't far from what reality would be. I appreciate your informed input here.

But still, as I described in the post, all these bits of tooling that other developers write seem to break all the time anyway. If you look at the quote from the Alembic developer, you can read the level of frustration and spent time that's been put into this. If this is how it's going to work, why not just do it in one location, as I said? All this tooling that's trying to add workarounds seems to be constantly breaking. I think that sqlite could do a better job implementing that logic itself. At the moment, with MediaGoblin, we're trapped and our developers and users are fighting these problems on a very regular basis.

I believe that the constant reimplementation of this in migration frameworks is indication enough that it really is desired and would be useful. Again, I encourage: if there's an experienced developer of sqlite, try testing my theory by running a crowdfunding campaign to add the feature. I bet you'll have proof enough through donations that this is something people want.

GitHub uses free and open source software, contributes to open source in some smaller ways, but their main product is a proprietary SaaS project... I don't think they count as an "open source startup"