Etherpad FAD planning starting up

[Mel Chua]

Hullo, folks - a number of us have been talking about doing a FAD on 
Etherpad (web-based gobby, essentially - I think most people here have 
seen it), and it's time to move those planning conversations to a public 
mailing list. I thought this one would be the closest to what we needed 
for the event/execution planning, since it crosses through multiple 
teams. We'll try to move upstream with our development conversations; if 
this isn't an appropriate place, please let me know where else I should 
be taking it.

The event page is at https://fedoraproject.org/wiki/Etherpad_FAD, and 
it's awfully stubby right now, but will be filled in pretty soon.

I should also explain that a bunch of folks involved in this are doing 
so as their first major Fedora contribution. All of us have ties to Olin 
College, which is the proposed location (Needham, MA, USA). Most of you 
already know myself (Olin '07, mchua - "zomg let's see if we can make 
upstream a stronger community"/QA person) and Sebastian Dziallas (Olin 
'14, sdziallas - packager who's done basically all of 
https://fedoraproject.org/wiki/Etherpad so far), but joining us in 
hardcore-planning-mode are...

* Colin Zwiebel (Olin '12, czwiebel - js hacker and event coordination 
ninja)
* DJ Gallagher (Olin '07, <getting-used-to-IRC> - js hacker and 
indecipherable-code-to-English translator)
* Andy Pethan (Olin '11, andyp - interface/user guru).

We plan on drawing in local and not-so-local Fedora (and hopefully 
Etherpad, if we can get someone from the original team in!) hackers for 
the event (October-something-or-other, likely) and part of our goal is 
to get Etherpad deployed in Fedora, at least at a 
"ready-to-go-into-staging" level, and in a better state as an upstream 
than they are currently (it's nearly impossible to decipher the code, 
there is no ticket tracker, the discussion is scattered, there's no 
release cycle, etc...) - the functionality/interface of the software is 
so strong and such a *great* collaboration tool, particularly for those 
not of a development background, and helps new contributors start so 
much, that we think it's worth going for. I mean, "First" *is* a 
foundation. ;)

In addition to the actual hacking of Etherpad, we're using this event to 
teach Oliners the Fedora/FOSS way of doing things, and how to get 
involved in Fedora, with a concrete project folks can dive in on with 
their existing skill sets (i.e. "everyone is coming in at a high level 
of some skill we need"). Copying Ryan Rix so he's in the loop, since 
this seems like something that could potentially fall under the Campus 
Ambassadors umbrella (as it's at a college and run by students as part 
of FOSS outreach within their community).

So, to resume the conversation, here's a bit of context on where we are 
right now

Colin Zwiebel:

Mainly, I'm concerned that EtherPad may fork a bunch of different 
directions or will continue to be a neat, difficult to use project that 
will flounder. I mean, it doesn't seem easy to break into the EtherPad 
foundation. Communities need to be accessible, its the only way you get 
people to contribute patches and ideas. But I think I'm just being 
pessimistic.

DJ Gallagher:

In terms of technical hurdles to community formation, and at the risk of 
continuing to sound like a Java fanboy recklessly derailing a Linux con, 
I feel like there's a missed opportunity in this not being somewhat 
friendlier to the at-large community of young hip developers who know 
how to work elements of the common toolchain of Java and Scala. More 
specifically: JVM applications aren't meant to be packaged in ways that 
negate the cross-platform goodness of the JVM. If the mysqldb setup is 
hateful, then developer builds of the app need to be able to forgo that 
setup and point to a shared dev database instance. If the app needs to 
be packaged with its libraries arranged just so, you write Ant scripts, 
which express such tasks in an elegant and compatible way.

There's still a lot of things I don't know or understand, like how 
EtherPad integrates a webserver, does it use anything resembling the 
Java servlet spec, or am I just thinking in completely the wrong frame 
of mind imagining that it would be treated like a Java project that 
you'd want to build with Ant or Maven and run on something like Apache 
Tomcat.

I can only say standardization tends to be win, because code in JRuby or 
Groovy or Scala that uses the servlet API can be ported to many 
different server front ends, or for that matter the cloud via Google App 
Engine. Probably the same thoughts Google had on the matter.

I'm not sure where I was going with this, but I thought I should 
volunteer that information. I can't code my way out of a bag in Scala. 
Are we hurting for someone who can?

...

I've read a bit more of the source code now, and I stand corrected on 
some of these points. While EtherPad requires the servlet API as a 
dependency, it isn't a java webapp, so much as it is a Comet protocol 
provider, with an embedded Jetty server as its Comet stack. I may be of 
some assistance in explicating the server and servlet components, but I 
would not claim to know how the code ought to be packaged or deployed or 
whether its dependencies are going to pose problems.