Developer Community Kickoff - Project Management Decisions

  • Welcome top backers of Eco! I wanted to kick it off with a discussion of the things we're currently thinking about as we work towards our alpha, and our evolving thinking about to integrate this awesome community into the game.

    <b>Open Source</b>
    One thing we're considering is how to open the source to Eco safely. We're planning to do something really unprecedented with Eco, opening up as much of the code and art assets as we can and sharing it with this community. There's a number of dangers in doing so, specifically it's a given that the code will instantly be pirated and spread through the internet. The question becomes: is the damage done by that worth the benefit of having a community of awesome developers joining us? I think the answer is yes, and that the damage of having our source in the public view is less than expected.

    The other issue is licensing. This is something that I think needs to be fairly stringent, to protect against the case of someone simply taking all the code, compiling it themselves, and selling the game separately. That needs to be illegal to protect the IP investments we've , so if it happens on a significant scale we have some recourse. We're going to be looking into source licenses that allow us to share the code, but anything that is created with the code belongs to us. However, I also think it's fair that major contributors would get a cut of the profits, and I hope to figure that out on a case by case basis.

    There's also the danger that people will secretly take the code and change it enough so that we don't recognize it in their product, but I'm less worried about that - they would have a hard time catching up to the progress of our community.

    <b>Technology to use</b>
    We'll need to figure out what are the best apps to use for community development, as this is a new endeavor for us. We'll need to figure out these categories:

    Source control: GitHub probably? But we will need a separate depot for our art assets as they are rather large.
    Bug database: Jira?
    Project planning: Trello
    Chat and project management: Slack?

    Once we figure these out we can start preparing the code for sharing with the community. Looking forward to hearing your thoughts.

  • Hi

    Regarding the bug database - I am familiar with Jira as we use this at my work for defects (and the devs use it too). Depends how cost-effective it is for you and what you want to do with it.

  • Regarding the licensing, it's fairly standard for a lot of large open source projects to have contributors sign an agreement before submitting patches, handing over copyrights to the collective "Developers of X" so that the license is still valid. I'm more than happy to sign such an agreement to give you rights to any code I submit. You probably just want an "All rights reserved" license, to prevent those with access to the code from re-distributing in a "modified" form for free.

    Re: source control: GitHub is expensive for organisations but would be nice. Maybe BitBucket or GitLab?

  • @jkxyz, while I have personally used bitbucket for 90+% of my own projects, I don't think it would be a good fit for this use case. Bitbucket and gitlab's pricing scales with users, whereas github's pricing is per-repo. Given that we'll have many users (team+all of us free labor folk), but few repos (most likely just one), I think github is the clear winner.

  • i'm not 100% familiar with GitHub, but lets say we use GitHub as the source control. Would the "issues" tab not be suffice for tracking bugs? If not, is there a way to tie that into Jira (i'm pretty sure there's a plugin for GitHub in Jira?)

    Excuse my ignorance

  • I've always preferred Jira for project planning and Bug tracking. Though jira is expensive I don't know if you would get a open source license for the project. But you probably know more about that.

    I love both Github and bitbucket, Github charge for repos and bitbucket charge for users, so probably github. But most games companies use perforce for its ability to deal with binary file. so you would need you own server for this, and its also expensive, infact more than i paid for the dev package per user.

    I think the cheapest would be trello for tasks, mantis for bugs, Gitlab for source, skype and google docs for management and chat. And a file server for assests. I think the only cost would be the servers.

  • Yeah we could host something ourselves, might by ideal if we want to scale to many users. Perforce is free to some number of users right? Would be harder to scale that one, unless they had some kind of open source special mode (probably not).

    Using SVN right now which lets us keep our code and art assets in the same tree, separating them out would be a hassle, the way Unity intermingles them, though maybe there are some standard solutions for that?

    Has anyone used Slack? Wonder if that would be a good fit.

  • Hi all, I personnaly think that GIT is more appropriate than SVN for such kind of external/shared project.

    That aside, GitHub is cool (and also the bug tracker with pull request link) but maybe a Jira would be more appropriate due to attachement functionnality.

    Regarding licencing, as someone exposed, having a contributor agreement to sign is a common way to do but feel free to propose any way.

    I still deligth to contribute to this wonderfull project.


  • I haven't used slack extensively but maybe a good way to aid communication between the dev team & community. Pretty much similar to slack from what I can gather but for a communication solution, hipchat may be a better fit integration wise with Jira and/or bitbucket since it's from the same company.

  • My biggest concern for you guys is how this will work from a management point of view. Any comments on that @JohnK ? If there's lots of contributions, someone needs to manage the codebase and make sure that feature trackers get updated.

    From a technical point of view, that makes BitBucket + Jira an excellent choice given that they integrate well. Slack is also great for remote teams from what I hear.

    For large assets, Git has lots of options. There's git-annex, which is a plugin which lets you store large files separately on a file server, but they can be checked out with the repository. Or new versions of Git have Large File Storage (LFS) built in, which I think does something similar. LFS has beta integration with GitHub but it's more expensive than just setting up an S3 bucket.

  • I am not quite sure exactly what you would like to open source but I would put my vote for an MIT license, as it would allow for the most people to work and leverage the work that happens. The main thing would to just not use a GNU license if we could, would be my recommendation. I also second the opinion of the contributor agreement, and if there is one I would definitely recommend adding a section about compensation like compensation is not guaranteed or whatever you would like.

    I would like to make a vote for gitlab and hosting it ourselves, by using the community edition:

  • Haven't used slack, but it looks ok, it's also free for unlimited users and unlimited which is always good. If it doesn't work it can always be changed.

    Perforce does lot like they do a free version for up to 20 users. But will that be enough? I currently use SVN at work, its simple and it works.

  • If they are using SVN right now, is it worth the time/effort to transition this to git? I understand the benefits of git, just concerned if this would just cause more bad than good.

  • SVN has worked well for us so far, but transitioning to something open source, with the potential to accept outside contributions, I think we need something more sophisticated, that handles branching well. Basically source control where we can have full control over what goes into the main branch, but users can create side branches and mess around all they want. If something has unlimited users thats going to be better, so we can scale up a lot of users if we want.

    Github with large file storage sounds pretty cool, wonder if it's stable enough to use/cheap enough?

  • one other thing have you thought about where you would store documentation?

  • Good point, probably keep using Google Docs, and just share it to the community

  • Also will documentation be made by hand or will some of the documentation (see the python documentation for a great example) be generated from the doc strings? If so what program will we use to generate the documentation? (ie what syntax needs to be done to the docstrings to make it readable by the program?) and will we also want basic user documentation made? or just a wiki that the community contributes to to give a basic user guide?

    Also if we use the gitlab community edition and host it ourselves then it is completely free for however we want to use it ("completely free and open source (MIT Expat license)" from the gitlab community page) I don't know if we have the resources to host one though, for that github might be nice since they will potentially allow for more users.

  • Source control: GitHub probably? - <b>Love Github. :D</b>
    Bug database: Jira? - <b>I am familiar with Jira so i would be fine with this.</b>
    Project planning: Trello - <b>Pretty common now and days, and for good reason it works.</b>
    Chat and project management: Slack? - <b>Love Slack, i switched our entire company to it when i got hired as IT Director.</b>

    As far as a depot, you could easily set up a server with OwnCloud installed (free) and then use WEBDAV to connect the "remote hard drive" to your computer. It's one option.

    What someone said above, Gitlab works well, i have used it in projects before it can be a stickler some times with configuration but nothing extreme. But github repo's can be private as well, but it cost per user slot i thought.

    P.S - Afaik.. Slack requires company e-mail addresses, you can allow multiple domain e-mail addresses however to sign up (i run 4 community sites, so i generate e-mails from all 4) but i have never tried with a common domain such as gmail.

    I have used all of these technologies plus several other kinds (as im sure people above have to) so if you are looking for something specific in any of these that would be the question to ask. But no matter what, Git (Community edition or normal) is a personal preference for code repo.

  • <blockquote>P.S - Afaik.. Slack requires company e-mail addresses, you can allow multiple domain e-mail addresses however to sign up (i run 4 community sites, so i generate e-mails from all 4) but i have never tried with a common domain such as gmail.</blockquote>
    From my understanding, an invite can be sent out by the dev team to enable backers to sign up via their own email addresses.

  • Well that would be good, as i said i have never tried it with common e-mail domain addresses. Hopefully it works fine bc i love slack plus then i can be in the slack dev chat at work and no one would know! >;D

Log in to reply