Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Why fork? #34

Open
FreekPaans opened this issue May 22, 2017 · 3 comments
Open

Why fork? #34

FreekPaans opened this issue May 22, 2017 · 3 comments
Assignees

Comments

@FreekPaans
Copy link

Hi all,

Nice to see you're using alibi as a base for this project. Is there any specific reason why you've chosen to fork it instead of contributing to the main project? It's of course perfectly fine to do so, but we can probably make it a better project by collaborating.

Cheers,

-Freek

@billota
Copy link
Member

billota commented May 22, 2017

Hi, @FreekPaans! We love that you created Alibi :-) We had been looking at using another solution that simply offered way more than we wanted ... which wasn't written in Clojure, LFE, or Erlang -- so our devs weren't too happy about updating it with all the changes we would need. We really wanted something like Harvest, but which we hosted ourselves. We'd looked for a Clojure solution last year, and decided to do our own, but never had the time. We needed an app even more this year, and then we found Alibi!

So, thanks again :-)

As for the fork, there were a couple of reasons we opted for that approach:

  • our designers wanted free reign
  • the backend developers wanted to re-org that part of the code base along the lines that we have done with our other supported Clojure apps
  • the frontend devs wanted to re-architect the Alibi implementation using core.async channels in Om's shared state, which they felt would be better done if a namespace re-org happened first; these are big changes that will drastically change how the underlying bits operate
  • the storage team wants to explore additional backends (most likely Redis and Postgres); these might actually be the most amenable to PRs, though

Alone, any of these might have pushed us towards a fork; all together, it was just too much. We didn't want to inflict them on you. Furthermore, there's been some learning as we go, with subsequent and unexpected changes that were even larger than the first changes ... this would be incredibly disruptive to anyone trying to maintain a stable base. These are likely to continue for a while, until we have the new core.async approach hammered out (and all the Om roots, views, components, etc., where we want them in the namespaces).

All that being said, if there are bits that you like, I'll make sure some of the devs get some time to contribute PRs back upstream.

We hope that you take our work on Alibi's new sibling as the highest compliment, with no offence! (And we hope you like the Icelandic name we chose for it :-))

All the best,
the BilloSystems devs

@oubiwann
Copy link

Hey @FreekPaans, I've talked to @billota about this, and can offer a solution that should benefit all. I've taught the team at BilloSystems Clojure and LFE and have paired with @ryugi on timi. How about this:

  • I'll open a ticket on alibi to discuss bringing in any changes you might like
  • I'll provide a list of features/tasks we've implemented in timi
  • then you guys can select which you like and order them by preference, and I can then start creating branches and submitting PRs

This way everybody wins :-)

What do you think?

@FreekPaans
Copy link
Author

Hi all,

I indeed take it is a compliment :) I understand the considerations.

@oubiwann that sounds like a plan! Looking forward to the issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants