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.

Sign up for GitHub

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

Jump to bottom

Intent to Fork Codebox #521

Open
initcron opened this issue Jan 21, 2017 · 15 comments
Open

Intent to Fork Codebox #521

initcron opened this issue Jan 21, 2017 · 15 comments

Comments

@initcron
Copy link

initcron commented Jan 21, 2017 •
edited
Loading

Codebox is such a amazing product, that even if this has no recent updates, it still continues to work well with the base features. What we love about it is in addition to the IDE, it also comes with a terminal built in, unlike a lot of other alternatives.

At School of Devops, we conduct trainings for ops folks, who need to write automation code and deploy to a cluster of nodes. We are using codebox along with docker to build/simulate multi node cluster running inside a single VM. Prior to this, we would have to rely on multiple VMs, which would turn out to be expensive on resources, and in many cases, would not work on a personal laptop.

Even though, the basic features are great, we need to start adding new features, making changes to suit our multi node environment. After going through the commit history, long pending pull requests, and dormant status of this project, we have come to a conclusion that we may have to fork this project.

We, hereby would like to convey the intent to fork this project. If the maintainers/authors of codebox, would like us to continue maintaining this project, we would like to start contributing to the same project without forking it. However, if we are not able to contribute/make changes, we have no option than going ahead with the fork. We would also like to applaud the team who created this awesome project and appreciate you releasing it under a liberal Apache 2.0 license.

We intend to maintain the current source, license for the parts that we are incorporate and continue to publish the fork under the same license Apache v2.0.
@scrumit
Copy link

scrumit commented Jan 21, 2017

Why not request Samy to transfer ownership?

https://help.github.com/articles/about-repository-transfers/

@initcron
Copy link
Author

@scrumit thanks for suggesting. We would definitely prefer reviving it than forking. @SamyPesse could you transfer the ownership of the project to "schoolofdevops" organization account or my account "initcron" so that we could revive/maintain it ?

Thank you 🍻

@TylerJewell
Copy link

There are numerous legal issues with that request. CodeBox's copyright and trademarks are the property of @SamyPesse and others business. They would be in breach of their fiduciary to their shareholders to transfer ownership without an agreement and consent of their board and shareholders. Even though the software is offered as an open source license for the purposes of use and redistribution, ownership and accountability are a different element.

It took us (Codenvy) 18 months to transfer ownership of the proper IP into the Eclipse Foundation (eclipse che / eclipse.org/che). 9 of those months was the process necessary to obtain shareholder approval. The other 9 months was the rigorous IP review of the foundation (and in many cases we had to rewrite significant portions to pass IP ownership tests).

@cmmata cmmata mentioned this issue Jan 23, 2017
Closed
@AaronO
Copy link
Contributor

AaronO commented Jan 23, 2017

@SamyPesse and I (the original Codebox authors), no longer own the open and closed source IP related to Codebox. Codebox was sold ~2 years ago, because Samy and I wanted to focus on GitBook. The company that acquired Codebox had originally promised to maintain and develop Codebox, but hasn't really followed through.

As @TylerJewell pointed out, transferring ownership would be complicated, @SamyPesse and I can not help out, since we no longer legally own the IP. However since it's open-sourced under the fairly liberal Apache 2.0 license, you should be able to safely fork it.

It's sad to see Codebox unmaintained.

Given the current status and lack of lead or sponsor of the project, I would recommend two alternatives:

  • Codenvy / Eclispe Che lead by @TylerJewell
  • Cloud 9 (acquired by Amazon / AWS)

Both projects are well maintained and actively developed by commercial entities. I would actively recommend you take a look at them and figure out how to combine your efforts.

Samy and I actually considered partnering up with @TylerJewell a long time ago (pre-Codebox). I have great respect for him, he's smart, pragmatic and his involvement in the Codebox threads shows that he cares. I like his approach of focusing on the enterprise use case whilst also building a sustainable open-source project (I would like to believe Codebox somewhat helped sway them in that direction). Building a world-class IDE, business and open-source project, requires a champion/leader, @TylerJewell is a good leader, Codebox currently has no leader or champion which hinders it's success moving forward.

@initcron
Copy link
Author

@AaronO and @TylerJewell thank you and that helps clarifying a lot of things and the way forward. I just looked at Eclipse Che and it is promising. We are going to give it a try, see if it could map to our specific needs and decide the next course of action. @AaronO and @SamyPesse thanks for creating a awesome project such as this.

@TylerJewell
Copy link

@AaronO @initcron - Aaron and Samy are a lot nicer and professional than they need to be.

I agree with Aaron that it is a bit sad to see Codebox go unmaintained. The acquirers (stewards) of the project had made numerous public commitments to maintenance of the project, and they did not follow through on those commitments.

There was a point about 4 years ago where we had considered merging projects. This was before Eclipse Che existed as an open source initiated and CodeBox was doing quite well. Aaron and Samy had other ambitions, and Codenvy had a bit of a different orientation, so the puzzle pieces didn't fit at the time.

Eclipse Che was heavily influenced by Codebox. We had to bumble and stumble around with a couple of really bad releases before we centered in on what we felt was the important abstraction - a developer workspace. Where CodeBox was strong as the IDE client, Che was going to focus on the workspace. Che and CodeBox both have an IDE client, but Che also has a lot of technology around defining workspaces, establishing the runtimes within, and then dealing with project types. This complexity is useful for situations where you want workspaces to be portable from computer to computer, or where you want developers to avoid having to setup additional tools on their localhost system. If a developer already has a VM pre-configured on their localhost, then a Che solution may be more cost than the profit.

You can achieve your use case @initcron using Che, though - you can just have Che set up some very basic workspaces with your tool chain installed and then you can have those terminal calls delegated out to your host / VM where you are doing the clustering. Or, if you are more adventurous, you can just do it all within Docker containers and let Che handle some of that for you.

The hardest part of running an open source project is building ecosystem. My gosh is it hard. We are fortunate with Che to have committers / contributors from Docker, Red Hat, SAP, Samsung and a lot of really cool technology companies like Salesforce, RogueWave, Aesthetic Integration, Southbank Software, and the so forth. I think our engineers were more proud of the 500 forks they got more so than the github stars or the actual usage. With building ecosystem, it's all about process and engagement, so we are increasingly slowing down our development cycles, documenting clear rules of engagement for how pull requests and contributors get engaged, and even spending more time on automating how customizations and docs are done. These are the elements that take a long time to figure out, but having an open process means stronger ecosystem.

We hope that you enjoy cloud IDEs and can make a go of either Codebox or Che.

@nzinfo
Copy link

nzinfo commented Feb 6, 2017 •
edited
Loading

@AaronO @TylerJewell @initcron, And @ALL I've just made an effort that make codebox alpha5 running on the lastest node(7.4.x) . And there's still some bug in it. eg. hard to type Chinese in editor & terminal... ， But it just run.
https://github.com/coreseekdev/codebox

And may be , I should pick a new name for my fork. :)

@scrumit
Copy link

scrumit commented Feb 6, 2017

I was going to suggest you keep the name until I read this comment from here:

The last option is to sever ties with the upstream and declare yourself the new maintainer of the project. This should only be as a last resort and should only really be done when the upstream project is dead or has gone completely off the rails. That being said, this kind of software deadheading can actually breathe a lot of new life into a project - just look at how LibreOffice has managed to revive the OpenOffice project by severing ties with Oracle.

If you do this, you should rename your project to differentiate it from the upstream, explicitly state your reasons for the schism in your README, and be sure to give proper copyright credit according the the open source license they originally chose. Maintaining an open source project carries quite a lot of responsibility, so make sure you're prepared to care for the project once you create such a schism.

@ssutar
Copy link

ssutar commented Feb 9, 2017

@nzinfo Can you please help me with the setup of codebox for development? I am having trouble getting it working locally and could not find any related documentation. Thanks!

@nzinfo
Copy link

nzinfo commented Feb 9, 2017

Just do
$npm install .
$node ./bin/codebox.js run

Good Luck, have fun ; )

@initcron
Copy link
Author

initcron commented Feb 9, 2017

@TylerJewell thank you for a detailed reply and sharing your thoughts. Over the last two weeks, we have been evaluating Che as well as C9 and both look fantastic, are already matured and cater to most of the developer workspace and IDE scenarios. Great work with Che and I would recommend it for anyone who is looking for an alternative to CodeBox which is up to date, and has a lot many features.

Also keeping Che/C9 in mind, we have decided to not duplicate the efforts and and maintain a similar project and a general purpose cloud IDE. However, what we are looking to achieve for our workspaces are very specific set of features, and those alone. We also have specific parameters with respect to simplicity and resource utilization of the IDE environment itself. We are looking for something which is malleable and gives us a way to customize and build on top of, and possibility to drive it not through just plugins. We are still exploring all the options but looks like we would have to go with with CodeBox and/or Ace (the base) and base our work on it will or write a tool from scratch.

@abalter
Copy link

abalter commented Jun 3, 2017

FWIW, I have used IceCoder which is a great product. Very simple and straightforward, but not open source. On the other hand, I just tried Che, and when I loaded it up, I was presented so many options I had no idea what to do. It is not built for someone who just needs a good browser based source editor.

Codebox appears in the image to be something along the same lines. However, I'm not able to get it to run.

I'm pretty sure there is a place in the world for this project, and I think it's a shame to have it grind to a halt over technical issues.

I hope someone will fork it, rename it, refine it and call it their own.

@abalter
Copy link

abalter commented Jun 3, 2017

@nzinfo

balter@bcore:~/codebox$ node ./bin/codebox.js run
[log][local] Creating /home/balter/.codebox
[log][socket] add service events
[log][events] events are ready, reporting is debounced to 180s
[log][hooks] init hooks
[log][workspace] Working on  /home/balter/codebox
[log][events] event 'workspace:ready'
[log][users] init users
[log][rpc] add service fs with 9 methods
[log][rpc] add service packages with 3 methods
[log][rpc] add service users with 2 methods
[log][rpc] add service settings with 2 methods
[log][rpc] add service codebox with 2 methods
[log][packages] Load and prepare packages (17 dependencies)
Error: ENOENT: no such file or directory, scandir '/home/balter/.codebox/packages'
    at Error (native)
    at Object.fs.readdirSync (fs.js:808:18)
    at /home/balter/codebox/lib/packages.js:69:27
    at _fulfilled (/home/balter/codebox/node_modules/q/q.js:801:54)
    at self.promiseDispatch.done (/home/balter/codebox/node_modules/q/q.js:830:30)
    at Promise.promise.promiseDispatch (/home/balter/codebox/node_modules/q/q.js:763:13)
    at /home/balter/codebox/node_modules/q/q.js:824:14
    at flush (/home/balter/codebox/node_modules/q/q.js:110:17)
    at nextTickCallbackWith0Args (node.js:419:9)
    at process._tickCallback (node.js:348:13)

@initcron
Copy link
Author

initcron commented Jun 4, 2017 via email •
edited
Loading

@scrumit
Copy link

scrumit commented Jan 14, 2021

Please highlight the fork as a separate issue.

It might be an idea to submit a PR here of the readme that has the address of the fork.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
7 participants
@TylerJewell @initcron @AaronO @nzinfo @scrumit @ssutar @abalter