Upayavira,
+1
We have a lot of folks (myself included) who are very interested in wave, but
aren’t actively developing. We need to show the SwellRT folks that we have
something to offer from a contribution standpoint (e.g. coding, design,
documentation, etc.). If we can bring them some extra oomph, and the legal
structure of apache is also appealing to them, then and only then does it make
sense to move. To that end, I might encourage the SwellRT team to start trying
out some apache like behaviors. E.g. using a mailing list for decision making
and voting, etc. to see how they like it.
Thoughts?
~Michael
On 10/10/16, 4:14 PM, "Upayavira" <u...@odoko.co.uk> wrote:
I'm suggesting that before we go to the proposal phase, people just
start participating in SwellRT. Just do it. Let's see what you can all
accomplish over there - let SwellRT see what they have to gain, and let
Apache see how more vibrant and active SwellRT is as a community. Then
it will be a no-brainer for Apache to accept SwellRT.
Upayavira
On Mon, 10 Oct 2016, at 10:10 PM, Adam John wrote:
> Sorry to have missed you, Thomas.
>
> "Cant a date be set, a vote be taken, then either import SwellRT or not?"
> According to Upayavira there should be a proposal.
>
> This is what I've found: http://incubator.apache.org/guides/proposal.html
> Although this seems more targeted to new projects.
>
> So the process would be:
> (1) Create a proposal
> (2) Submit it to the group via email
> (3) Vote
>
> I've created this working document
>
<https://docs.google.com/document/d/1jhPRR9juJAhBBZ9qjYI5KxlaHSz-IJJdPQ6_3puwWBQ/edit?usp=sharing>
> to get us started - but not sure if the template at the link above is
> suitable.
>
> Talk soon!
>
> AJ
>
> Adam John
> (914) 623-8433
> Google+ <http://google.com/+AdamJohn1> | LinkedIn
> <http://mradamjohn.com/>
>
> On Mon, Oct 10, 2016 at 5:00 PM, Thomas Wrobel <darkfl...@gmail.com>
> wrote:
>
> > I am sorry I didn't make the meeting, glade to see it was productive.
> > However, I am curious though why there is questions still as to if
> > SwellRT should be merged with wave.
> >
> > Wave development at apache is nearly dead.
> > Doing nothing and it will have to retire. No one has proposed a 3rd
> > option that I am aware of.
> > So in terms of community engagement, not seeing a downside.
> >
> > If theres technical downsides, thats another mater. But not aware
> > anyones raised any yet.
> > From what I have seen possibly my only concern is the API to
> > communicate to the server is just in javascript - we would
> > eventually need alternatives if we want to allow native iOS and
> > Android clients.
> >
> >
> > "activity similar to this starts brewing and
> > then it all dies down in a few months"
> >
> >
> > True. Seen it many times.
> > Maybe too much discussion with too little actual discussions resulting
> > in anything changing.
> > Cant a date be set, a vote be taken, then either import SwellRT or not?
> >
> >
> >
> > --
> > http://lostagain.nl <-- our company site.
> > http://fanficmaker.com <-- our, really,really, bad story generator.
> >
> >
> > On 6 October 2016 at 18:21, Pablo Ojanguren <pablo...@gmail.com> wrote:
> > > Thanks Adam for clarifying the questions.
> > >
> > > Also I agree with Upayavira, the primary discussion it might be more
> > about
> > > "ideas" and the community's "engagement" with them. After that, tech
> > > aspects would come.
> > >
> > > So, in this regard I would like to share some thoughts about SwellRT
as a
> > > product...
> > >
> > > a) Where SwellRT fit in the market? Competitors?
> > >
> > > SwellRT current vision is closer to products like Firebase, Meteor and
> > > Realm.
> > > They are new breed of frameworks/platforms to write apps. They
provide as
> > > key feature, real-time data storage with simple document-based data
> > models.
> > > Their aim is to simplify and speed up web/app development. And of
course,
> > > they allow to build real-time collaboration features easily.
> > >
> > > Of course, these projects are matured, but they still have pros and
cons.
> > > What it seems clear to me is the trend: to develop heavier
apps/webapps
> > > (because nowadays devices have a lot of computing power and it means
just
> > > coding for one system) and lighter backends providing common
"services"
> > > (notifications, storage, auth...).
> > >
> > >
> > >
> > > b) What Wave/SwellRT's tech could offer in this market as innovation?
> > > Wave/SwellRT could compete with features like:
> > >
> > > - Open Source and JVM world: I guess there is still a part of the
world
> > > happy to see a Java friendly framework, despite it works for Web (but
> > > hopefully for android/iOS).
> > >
> > > - Simpler API: with sugar syntax, for example, in SwellRT we are
working
> > in
> > > a JS syntax just based in mutable objects. Also with API concepts
easy to
> > > understand: objects and participants.
> > >
> > > - Full-featured collaborative writing: Wave was designed for text
> > editing,
> > > whereas these new frameworks are focused in JSON. For example,
> > annotations
> > > is a cool feature not easy to provide I guess. Also the Wave's text
> > editor
> > > is very good yet.
> > >
> > > - Federation: it is the hardest selling point for developers in
general
> > > because it doesn't provide benefits in the short term. However, it is
the
> > > entrance to innovative things like cross-app interoperability, organic
> > > scalability...
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > 2016-10-05 23:47 GMT+02:00 Upayavira <u...@odoko.co.uk>:
> > >
> > >> I want to see a proposal regarding importing SwellRT that gives me
> > >> confidence that bringing SwellRT into Wave will actually lead to an
> > >> active project.
> > >>
> > >> A way this could be achieved *before* bringing SwellRT would be if
> > >> everyone who is interested in contributing headed over to SwellRT,
and
> > >> started contributing over there. Then, we'd be bringing both code and
> > >> community into Apache, which would give me far more confidence than
just
> > >> importing code but with no confidence that anyone is actually going
to
> > >> do anything with it.
> > >>
> > >> Upayavira
> > >>
> > >> On Wed, 5 Oct 2016, at 10:03 PM, Adam John wrote:
> > >> > Pablo, a lot of great information in this slide deck. I hope
others
> > have
> > >> > a
> > >> > chance to review as well. Outstanding work.
> > >> >
> > >> > Price, very thoughtful responses. I agree with the overall
> > conclusion -
> > >> > SwellRT should be brought into Wave.
> > >> >
> > >> > I like the idea of moving the SwellRT fork in to replace the
current
> > >> > branch
> > >> > of Wave development because it moves the project reasonably forward
> > and
> > >> > makes sense overall. It does not seem anything current would be
lost
> > in
> > >> > that move. It seems like we have everything to gain. However,
there
> > >> > might
> > >> > be work in progress that is affected.
> > >> >
> > >> > It would be great if contributors on the project took a look and
> > shared
> > >> > some thoughts.
> > >> >
> > >> > Q3) For current contributors; are you in favor of bringing the fork
> > home?
> > >> >
> > >> > -
> > >> > Great attendance at our last meeting, and familiar ground was
covered.
> > >> > (agenda
> > >> > and notes
> > >> > <https://docs.google.com/document/d/11j_
> > WQGYAtDlN8Wqx8jJglPpw6tJznvMGf
> > >> dLOvQu96i0/edit>)
> > >> > We're largely covering the next steps in recent emails.
> > >> >
> > >> > If the group agrees, that we should bring SwellRT into Apache Wave,
> > then
> > >> > there needs to be a proposal drafted.
> > >> >
> > >> > Q4) Does anyone have interest, experience or desire to help with
this
> > >> > task? We do not expect to start until after the next meeting.
> > >> >
> > >> > -
> > >> > Perhaps 2-3 weeks is time enough to consider the questions posed?
> > >> > I'd like to plan our next steps;
> > >> > I suggest *10/26 as the next discussion* - based on consensus in
the
> > list
> > >> > of course.
> > >> >
> > >> > The goal of the next meeting will be to provide a chance to address
> > any
> > >> > questions regarding bringing the projects together. Perhaps this
> > could
> > >> > be
> > >> > a technically deeper discussion.
> > >> >
> > >> > Q5) Does anyone have interest in a standing co-work session?
> > Especially
> > >> > important would be current contributors. I think this could be a
good
> > >> > way
> > >> > for some on the list that have stalled or reached impasse to begin
to
> > >> > make
> > >> > progress in helping out.
> > >> >
> > >> > Thanks, everyone for your work and efforts. I believe that if each
> > of us
> > >> > does just a little bit over the next few weeks we will continue to
see
> > >> > the
> > >> > progress we need in this project.
> > >> >
> > >> > Adam John
> > >> > (914) 623-8433
> > >> > Google+ <http://google.com/+AdamJohn1> | LinkedIn
> > >> > <http://mradamjohn.com/>
> > >> >
> > >> > On Wed, Oct 5, 2016 at 12:34 PM, Pablo Ojanguren
<pablo...@gmail.com>
> > >> > wrote:
> > >> >
> > >> > > Thanks for your answer Price,
> > >> > >
> > >> > > I guess we should not delay this discussion...
> > >> > >
> > >> > > I'd happy to run another call if you think it can move things
> > forward.
> > >> > >
> > >> > >
> > >> > >
> > >> > > 2016-10-01 18:40 GMT+02:00 Price Clark <gpwcl...@gmail.com>:
> > >> > >
> > >> > > > Pablo, thanks for the presentation.
> > >> > > >
> > >> > > > While my qualifications to answer this are 0 getting to
listen to
> > >> > > > Upayavira talk this week (the last Apache mentor if I'm not
> > mistaken)
> > >> > > make
> > >> > > > me feel the answers to 1 and 2 are easy to answer.
> > >> > > >
> > >> > > > 1.) Upayavira communicated very fervently that there just isn't
> > >> enough
> > >> > > > oomph in wave's development. Every year around the time that
the
> > >> > > retirement
> > >> > > > conversation is brought up, activity similar to this starts
> > brewing
> > >> and
> > >> > > > then it all dies down in a few months. From this perspective
"Does
> > >> > > SwellRT
> > >> > > > tackle current Wave problems?" The answer is unequivocally yes,
> > >> SwellRT
> > >> > > is
> > >> > > > a more actively maintained fork of Wave and given the
> > slowing/slowed
> > >> pace
> > >> > > > of Wave *a merge with SwellRT is likely the only way to save
this
> > >> > > project*.
> > >> > > >
> > >> > > > 2.) I would also like to bring up another point Upayavira made,
> > >> > > > "Communities are built around good ideas and bad code." Running
> > with
> > >> > > that I
> > >> > > > thing that good ideas attract tinkerers and 'people with ideas'
> > that
> > >> > > could
> > >> > > > eventually become 'contributors with ideas'. In some senses
> > SwellRT
> > >> > > > splinters Apache Wave in a way that developers on this mailing
> > list
> > >> have
> > >> > > > been alluding to for a while. The client side code is not well
> > >> understood
> > >> > > > and is definitely in the way of the server. SwellRT has a more
> > >> general
> > >> > > goal
> > >> > > > of supplying a server that is capable of powering a front-end
like
> > >> the
> > >> > > > original vision of google wave. This means that merging with
> > SwellRT
> > >> > > would
> > >> > > > force a separation of the client and server and allow for
people
> > with
> > >> > > > interests in either a front or back end to work in tandem. This
> > seems
> > >> > > like
> > >> > > > an ingenious way to attract more people; anyone with an
interest
> > in
> > >> the
> > >> > > > backend technology OR a way to use said technology in an
> > application
> > >> > > could
> > >> > > > be a potential contributor. Unless I'm mistaken it seems like
> > SwellRT
> > >> > > > offers a set of features that could be classified as a
superset of
> > >> Wave's
> > >> > > > features. So, it seems like most or all of SwellRT would be at
> > home
> > >> in
> > >> > > > Wave. Pablo also reasonably stated that he'd prefer to work in
one
> > >> > > project.
> > >> > > >
> > >> > > > As for me, as soon as a direction is clear I would love to
talk to
> > >> > > > someone actively maintaining/writing code so I can help them
> > >> contribute
> > >> > > to
> > >> > > > whichever code survives in whatever way possible.
> > >> > > >
> > >> > >
> > >>
> >
