social-discuss
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Social-discuss] The Case for Branching Elgg?


From: Samuel Rose
Subject: Re: [Social-discuss] The Case for Branching Elgg?
Date: Sat, 3 Apr 2010 10:58:24 -0400

Hello GNU Socialites.

On Sat, Apr 3, 2010 at 11:27 AM, Sean Corbett <address@hidden> wrote:
> It certainly seems doable and the code base is very nice and
> straightforward; Ian and I have actually been spending time with it trying
> to figure out a way to get two Elgg instances we've installed on our school
> network to "talk to each other."  Of course I think there would need to be a
> lot more work done on it to attain all the goals that we've established, but
> it would provide a useful basis for development.
>
> I'd personally rather write something completely new, but would be agreeable
> to it if that were the path we took.
>


I am having trouble figuring out why there is a desire to build
anything new, settle on one protocol, settle on website or desktop
application, reject existing standards, and in general create
either/or decisions around any of the approaches discussed so far.

What if, instead, you think about interoperability among all of these
options *first*, and create an architecture for an ecology in which
many can participate (irregardless of programming language, protocols,
nature of application, etc)? You've all got an opportunity to create
something really adaptable and re-usable outside of niche contexts
here.

What if there were room for new applications, existing applications,
new protocols and old protocols, applications written in python, ruby,
erlang, and PHP, applications based on webservers and applications
running from desktop talking to P2P networks? In this case, you'd need
some way to translate across these systems (we use
http://flows.panarchy.com/index.php?title=Main_Page for this in some
cases. It's not just for HTTP either) and a way to store data (many
ways are better than one way). There's really no need to narrow down
to one way of doing things, creating one monolithic application,
supporting some standards and not others.



> Would we be able to copyright assign all the code in our fork to the FSF? If
> not, branching Elgg is not a viable option.
>

I don't think there is even a need to branch ELGG, instead, it could
be more worthwhile to create a way to work with ELGG as it is (and
other web applications, too: insoshi, media wiki, Drupal, etc etc etc)

> --sean corbett
>
> On 04/03/2010 09:23 AM, Melvin Carvalho wrote:
>
> 2010/4/2 Brett Profitt <address@hidden>
>>
>> Hi,
>>
>> I'm Brett Profitt, the lead developer for the Elgg project, and was
>> given a heads up by
>> Melvin Carvalho on our community site [1] that Elgg's being discussed
>> as a possible solution for a distributed SNS by the FSF/GNU.  Awesome!
>>
>> Just wanted to throw a few things out to you guys:
>>
>> * The general roadmap and focus mentioned in this thread are basically
>> correct.  Heavy dev time went into 1.7 to fix long standing bugs and
>> API oddities.  While I'm pleased with the results so far, this is a
>> continual process of improvement in the project.  1.8 is focusing on
>> interface, UI/UX, and making it easier to theme Elgg.  It's planned
>> for autumn 2010.  A generic roadmap covering up to Elgg 2.0 was posted
>> on the community site [2] and will soon be examined in depth and
>> posted on elgg.org.
>>
>> * There's been a recent hugely positive change in Elgg's
>> community--not unrelated to a change in how Elgg devs approached
>> it--that's been really pleasant to experience.  Elgg's ecosystem has
>> reached critical mass where conversations are interesting and
>> worthwhile, the help vampires are dealt with quickly by community
>> regulars (and even a few recovering help vampires themselves), trac
>> [3] is buzzing with not only bug reports but *patches* and actual
>> joint development is taking place.  If you were in the community more
>> than 3 months ago and left, you might want to come back--it's better.
>>
>> * Federalization is starting to be big deal with Elgg.  Curverider
>> (the primary funding company for Elgg) are discussing ways to create a
>> federalization plugin using openID and OAuth.  There's some working
>> code and it's very likely significant parts of this will be opened
>> once the code is reasonably distributable.  This would be a great
>> project for joint development with some of the distributed web app
>> gurus that I'm sure are lurking.
>>
>> * Yeah, the G part of 'GUID' is a lie.  There's been talk about
>> creating truly global IDs, but this was left alone in favor of more
>> serious bugs and shortcomings.  Triage happens.
>>
>> * Elgg is OSS--if you need to change Elgg to make it better for you,
>> chances are your changes will make it better for everyone.  I'm not
>> familiar with the full scope of your project and I know that
>> branches/forks are sometime necessary, but I see them closer to a last
>> resort than a first reaction.  Community support and interaction has
>> increased dramatically going into the 1.7 release and it's just
>> getting better.  Whether it's interaction on trac / community or
>> something more official like a hosted branch on code.elgg.org, I'd
>> love to have you guys (gender-neutral) as part of that!
>>
>> I know this was a bit of an info dump, so if you have any questions or
>> comments, feel free to ask.  If you're up for some IRC action we're
>> #elgg on freenode.
>
> Hi Brett
>
> Many thanks for taking the time to post.  Not 100% sure which direction the
> GNU Social folks will go, but I'm pretty convinced by your arguments.  What
> I've seen of elgg so far I like.  I'd encourage GNU social to jump on board
> at either the 1.7 or 1.8 marks, but am unsure what will happen in the short
> term.  Matt Lee, the lead dev, asked me to set up a test instance which ive
> done here:
>
> http://gnusocial.me/
>
> Independently, I have 3 php devs, and we've decided to get more involved
> with elgg, with a view to contributing code.  Your community seems open and
> friendly, which is a huge plus for us.
>
> Our area of expertise is semantic web technology and that's where we'll aim
> to start offering patches in that area.
>
> I've already located a security vulnerability with the sha1mbox ... if you
> take a nick and add @hotmail.com @gmail.com @yahoo.com etc then take an
> sha1sum you can often reverse engineer the email address, so that's
> something we can fix up too.
>
> W3C is also known to be looking for a social networking site for their home
> page, so if I can get elgg to a state where it's pretty standards compliant,
> hopefully we can push that forward.
>
> I've bookmarked #elgg on freenode, so perhaps we can continue conversations
> there.  I'm looking forward to a hopefully great collaboration!
>
> Best wishes
> Melvin
>
>>
>> Thanks,
>> Brett
>>
>> 1. http://community.elgg.org
>> 2.
>> http://community.elgg.org/mod/groups/topicposts.php?topic=453453&group_guid=212846
>> (4th comment down...comment permalinks are in trunk!)
>> 3. http://trac.elgg.org
>>
>> ----
>> Brett Profitt
>> Elgg Lead Developer
>>
>> Skype: brett.profitt
>> Twitter: http://twitter.com/brettprofitt
>>
>>
>
>
>
>



-- 
-- 
Sam Rose
Forward Foundation
Social Synergy
Tel:+1(517) 639-1552
Cel: +1-(517)-974-6451
skype: samuelrose
email: address@hidden
http://socialsynergyweb.com
http://forwardfound.org
http://socialsynergyweb.org/culturing
http://flowsbook.panarchy.com/
http://socialmediaclassroom.com
http://localfoodsystems.org
http://notanemployee.net
http://communitywiki.org
http://p2pfoundation.net

"The universe is not required to be in perfect harmony with human
ambition." - Carl Sagan




reply via email to

[Prev in Thread] Current Thread [Next in Thread]