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

Juniper and Thebelab #2

Open
nthiery opened this issue Jan 5, 2019 · 4 comments
Open

Juniper and Thebelab #2

nthiery opened this issue Jan 5, 2019 · 4 comments

Comments

@nthiery
Copy link

nthiery commented Jan 5, 2019

Juniper and Thebelab seem to tackle the same problem, with -- if I understood correctly -- similar approaches. Is there an intrinsic reason preventing the two project to converge? E.g. by merging Juniper's cool additional goodies (e.g. CodeMirror cells, ...) into Thebelab?

Cheers,
Nicolas

@Miniland1333
Copy link

The implementation of persistent binder instances is quite useful! For end-users, having to wait for Thebelab to reload on each page has been quite dull and Juniper's approach reduces the time that they have to wait!

@nthiery
Copy link
Author

nthiery commented Jan 11, 2019

That's indeed a very nice feature. Do you foresee any barrier to contributing it back to Thebelab?

@Miniland1333
Copy link

I am not familiar enough with the underlying code myself, but I think that we could open a branch on Thebelab dedicated to porting over functionality. It look like this is allowed based on the license as long as credit is given. @ines would you be interested in this?

@ines
Copy link
Owner

ines commented Mar 27, 2019

@nthiery @Miniland1333 Sorry for only getting to this now. To give you some background:

Is there an intrinsic reason preventing the two project to converge? E.g. by merging Juniper's cool additional goodies (e.g. CodeMirror cells, ...) into Thebelab?

I started off by using Thebelab and later a custom build of it, but I ended up rewriting it pretty much from scratch in a way that makes it easier for me to maintain, especially for use in the spaCy site. At that point, I thought it was fairest to maintain my own fork instead of trying to push all my changes upstream.

For example, I would never go and open a PR on someone else's project like "Replace jQuery because I personally dislike it" – I think that's unfair to fellow OSS maintainers. If I want to rewrite code like this, I need to accept the maintenance burden and fork it.

But of course, everything I changed and did is open-source and published as MIT, so it can be reused by others or adopted again.

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