Move everything to GitLab #15

Open balupton opened 10 years ago

Why?

Follow our libre values
Increase diversity of the playing field to prevent monopoly side-effects which are currently evident in github e.g.
- staticsitegenerators.net only supports github
- people use the argument, everyone is already on github — which spirals the issue further
- we use github for things we probably shouldn't be using github for, i.e. support, discussions, etc.
Increase support of a libre alternative
A bit of what is mentioned here: https://github.com/DamonOehlman/damonoehlman.github.io/issues/22

Todo:

Create script to create repos on gitlab
Create script to populate those repos with all the branches and tags of the github repos
Either manually or via a script, re-add the teams
Update cloudflare URLs to DocPad resources to point to GitLab locations
Update GitHub repos master branches with a redirection notice
Don't care about issues, let them sit on github, a fresh start is always good
Do up a blog post about why the move

/cc @bevry/meta-team

I do agree switching to GitLab is a good idea.

@gitlabhq if we postulate that moving all of bevry's projects to gitlab creates a snowball of other projects and communities doing the same, is @gitlabhq ready for such a thing? does it wish for such a thing?

Is it beneficial for you/gitlab to have github incur the loss of hosting open-source projects? Or would you like to incur that cost for the benefits of exposure, feedback, and statistics?

Asking as bevry are the creators of two really popular github projects: https://github.com/docpad/docpad and https://github.com/browserstate/history.js

We can ask GitLab no? :) Get in contact with them if you like. These questions are best answered by them. :)

@Greduan ... I believe the @ of them should notify them... no?

Maybe? From my experience @mentioning an org doesn't work. Only mentioning a group inside an org. But you can still try. :)

I'll just do it for you in order to test. :)

@gitlabhq, if you guys are notified, sorry for bothering you guys. :)

We just have a question, check above for what that question is.

This is an experiment as I believe orgs don't get notified of mentions but I thought I would test it.

@Greduan good catch on the username thing, I've updated my original post.

I've also pinged them on twitter just in case: https://twitter.com/balupton/status/507912394924756992

Thanks for the ping on Twitter! As I'm the CEO of GitLab B.V. (running GitLab.com) I'll respond.

Are ready for such a thing?

As ready as we'll ever be. If there are any performance problems we'll fix them but I don't expect any.

Does it wish for such a thing?

Yes, very much. We would like everyone to know what GitLab offers and moving your project to GitLab.com would expose many more people to it.

Is it beneficial for you/gitlab to have github incur the loss of hosting open-source projects? Or would you like to incur that cost for the benefits of exposure, feedback, and statistics?

The latter, the benefits of spreading the word about GitLab far exceed the hosting costs.

We welcome you with open arms. Please let us know if you have suggestions to make GitLab.com a better place. Feel free to build upon https://github.com/gitlabhq/gitlab-recipes/blob/master/import/github/import_all.rb to do the move (and contribute back you changes).

Awesome! :D Thanks for your answer @dosire. :)

So we can move when we're ready I guess @balupton.

Is your idea to move everything to GitLab now or would you prefer to start by hosting the new DocPad on GitLab and then move other stuff later on?

@Greduan You're very welcome, let me know if you have any other questions.

Will do. :)

I'm satisfied. All that needs to do now is develop the necessary scripts for the migration.

Love to do this as a Chainy script. @Greduan — want to take a stab at this using chainy?

One thing that should definitely be stated, is that this move will nosedive our GitHub contribution activity. Considering it is a vanity metric, I'm not too concerned, it may actually be beneficial on some levels — while being detrimental on some.

Well I did get some experience with Chainy when I made download-gist but I'm not sure what needs to be done...

I'll look into it. Basically just a script to move the GitHub repos to GitLab.

Should I register an account for Bevry and DocPad and such or would you like to handle that? Also would we host it ourselves or would it be on GitLab.com?

Found this: http://doc.gitlab.com/ce/raketasks/import.html

Looks like it's already automated for us... I'll test this with my own repos, hopefully today.

Oh wait, that's for self-hosted stuff not for the public GitLab.com instance. So I guess I can make a script but first, will we self-host or not?

DigitalOcean has a pre-prepared image with GitLab installed in it.

@Greduan let's not self-host, the less fragmentation the better.

Perhaps GitLab can help us? @dosire does GitLab have any migration tools for migrating all our repos to GitLab, or is that something we should create? Also, congratulations on GitLab, you and your team have done a very great job. Well done :-)

(Just found this thread; sorry for the late reply!)

if we postulate that moving all of bevry's projects to gitlab creates a snowball of other projects and communities doing the same

I disagree. When a field is as dominated by one player as OSS development is dominated by GitHub, it is extremely hard to break that hold.

For example: Facebook dominates social media. Within Facebook, there are several organizations, many of which are reasonably sized, and which do good work. Now…suppose one of those organizations left Facebook for a more benevolent social network. Or even two or three of them. Do you really believe this would create a “snowball effect”, resulting in a mass exodus from Facebook to the more-benevolent social network?

Of course not. Everybody knows that Facebook is quite possibly the sleaziest, least trustworthy company on the Web. (If you disagree, I’d feel confident that you’d concede that it is in the top five such companies, at the very least.) And, in fact, people have tried to create trustworthy, privacy-respecting alternatives to Facebook (like Diaspora, Friendica, and Tent).

Diaspora launched in 2010. Although its decentralized nature makes it harder to get concrete numbers for its user base, the best I could find puts the number around 380K. After four years.

Four.

Why? Well, it’s not because people prefer to have their privacy invaded, and it’s not because people like one central company to amass dangerous amounts of personal information to sell to advertisers (and god knows who else!). It’s because people are on Facebook. It has all the social capital, and—from the standpoint of where people choose to put their time in—that is more important than ideology, decentralization, technological advantage, and privacy.

I dislike this intensely, but it’s true.

For a while, people were pretty angry at Twitter (even though it is a more ethical company than Facebook, by orders of magnitude). So, some people tried to get a “snowball effect” rolling for their alternative, Identica.

At 1.5 million users, it’s been a more successful “benevolent alternative” to Twitter than Diaspora was to Facebook. But that’s still less than 1% of Twitters 241 million users (source).

GitLab may have more merit going for it than GitHub, but that’s not enough. Moving everything to GitLab will:

Cost a lot of time and effort to migrate the codebase
Cost a lot of time and effort for existing developers to readjust their workflows and learn the differences of GitLab
Most important of all, it will reduce the visibility of every last project to a small percentage of the current size.

And don’t think that linking to the new location will help. The alternative social networking sites I mentioned above had massive campaigns, many of which were prominently featured in tech magazines and blogs with millions of viewers. Linking from a popular old location to an unpopular new location does not work like forwarding e-mail; traffic won’t simply follow the link and continue the same behavior at GitLib like nothing’s changed. Perhaps a few individuals might…but you’ll still lose far, far more contributors in the end.

And what happens to open source projects that cease to be developed? They die. And the communities that once breathed life into them die, as well.

I cannot protest this idea strongly enough. If you move to GitLab, perhaps you can keep the company’s core developers active enough to keep the projects alive. Perhaps you might even find some short-term success in convincing a few contributors to keep working on your projects.

And if you move to GitLab…I really, really hope that they do. But I think that moving to GitLab will do as much good for your repositories as moving them to a private server for bevry employees only. Slightly better than that, perhaps…but not by much.

I would love to be proven wrong about what I’ve written here. But I don’t think that I am.

Please: reconsider this. Not just for the company, and not just for the good of your software, but for your extended community.

I believe that what is good for your extended community is also good for your software, and your company, too.

Please reconsider.

Those are some very good points you make @Zearin.

I personally believe that it will create s lightly larger snowball effect than with Facebook and Twitter, mostly because developers are in average much more aware of privacy and open source and the benefits of open source, etc.

Diaspora and Identica didn't have nearly as much success as the originals but one must realize that 99% of the people using the originals are not techies (most probably) and certainly most of them don't understand a concept such as privacy on the internet.

GitLab will have a greater success because it is targeting a market that is already aware of the benefits it brings, you don't have to explain it to them.

However, if @balupton wants we can put it up for vote. Have a one week time frame where people can vote and we go with whichever got more votes. That is of course if you agree as well Zearin. :)

I personally believe that it will create s lightly larger snowball effect than with Facebook and Twitter, mostly because developers are in average much more aware of privacy and open source and the benefits of open source, […] GitLab will have a greater success because it is targeting a market that is already aware of the benefits it brings, you don't have to explain it to them.

In the end, it won’t matter.

It’s true that a tech-savvy audience will have a little more success than a general audience, but not much.

I don’t have figures for this, but anecdotally, I’ve observed that most of the users in those “benevolent alternatives” to mainstream social networking sites are techies. But are all techies on those sites? No? Not even a majority?

Social capital.

But more to the point: take a look at WikiPedia’s Category for OSS hosting sites. Now, consider these questions:

How many have you heard of?
How many have you browsed projects on?
How many do you have accounts on?
How many are you regularly active on?

I’m willing to bet that at each question, your answer became smaller and smaller. Why?

Social capital.

All the other things—the preference for this or that technology, the association with this or that organization, the principles, the site’s design and ease of use—they do matter. They just matter a lot less than social capital.

SourceForge ruled OSS for over a decade—despite a horrible site design, slow adoption of decentralized VCSs, and an overall high barrier-to-entry. It managed to stay the leader because of—you guessed it!—social capital. SourceForge was where all the people were.

Google Code eroded it a little bit, as did Launchpad (to a lesser degree). But even then, SourceForge was still king.

It took GitHub to dethrone SourceForge.

Unlike all the others, GitHub had a perfect storm going for it: a lot of developers were discovering git, and the beauty of a decentralized VCS (Launchpad tried with Bazaar, but it never caught on, perhaps because Bazaar’s emphasis on performance was secondary, whereas it was a primary design goal for Git); people had, I suspect, been sick of SourceForge’s ugly, difficult-to-use website; and, GitHub built a beautiful interface that smoothed over a lot of the complexity of using Git on the command line. They managed to make a site where anyone could contribute to open source, and they could do 100% of it on the website, if they wanted.

That’s how GitHub achieved its meteoric rise: perfect timing, a large user base at SourceForge that was hungry for something better, and a website that made contributing so easy that longtime would-be contributors finally got involved.

Something similar happened when Facebook overtook MySpace: MySpace was king, and they had all the users. But MySpace was ugly as hell, and it didn’t do everything that people wanted. So, it had a large population of unsatisfied users. With a superior product and a large dissatisfied user base at MySpace, Facebook managed to take over as the king of social networking.

But that won’t happen here. There are complaints about GitHub—legitimate ones, to be sure. (I really want GitHub to open source their own site, for f@%!’s sake!) But is GitHub’s user base tired of GitHub? Are they only hanging around because everyone else is here, or are they ready to jump ship for the first competitor with a superior product?

Well, for the most part, people love GitHub. The complaints are real, and they’re not going away; but they don’t outweigh what people love about GitHub—not by a longshot.

Unless the right timing and ingredients come together for a competitor to topple GitHub, any hope of inspiring a “snowball effect” exodus is a pipe dream…techies, or no techies.

as much as i distaste closed centralized systems, i have to agree with @Zearin. in terms of our open network and our social mission, i think we will lose more than we gain by moving to GitLab. i think we are better off supporting the next generation of social coding tools to be decentralized and open source.

And what happens to open source projects that cease to be developed? They die. And the communities that once breathed life into them die, as well.

There's quite a jump between lack of contributors to a project dying. A project dies when people no longer have use for it.

@Zearin for the most part I agree with you, I had the same fears, however recently they've dissipated themselves.

There's a resurgence forming in my opinion, where people are uncomfortable using a closed-sourced tool to develop their open-source tools, as well as placing that much power into such a company, it reduces diversity, and creates that peer-pressure situation you've described and is the source of your fear.

Yes, the snowball effect may not happen, but does it matter? A corollary to that question is: should fear of possible consequences prevent people from doing the correct thing? I don't think so.

For the most part, project exposure is detrimental in my opinion. It turns a fun project into a product that must be supported. In open-source this is dangerous, especially when there is no clear funding yet that actually works for open-source projects. Most are consumed, and die for lack of resources. Directly limiting their exposure, I'm betting, is going to be beneficial. After all, it's about community, not consumers. Projects survive when the problem they solve still exists, and it is still fun working on the project, and you still have the resources to maintain it and keep it fun. Furthering this, GitHub's exposure is driving open-source maintainers mad — when you open you inbox to 1000 issues, and you're just one person, there's no way to say that's a good thing, when you need a 100 more you's working for free, going into debt for your rent, to deal with that. Having an unpopular project that is still fun and growing, is always better, than a popular project that is stressing and imploding.

There's also only one way to find out if any of these concerns are valid, and that's just to do it. It could be that all the fears become a reality, then hey, we may bite the bullet, and move back. It could also be that the concerns turn out to be just FUD and never actualise, and it becomes a great decision. Either way, there's only one way to find out.

GitLab has comes leaps and bounds recently, and I use it already myself a fair bit. It's a good contender to GitHub — unlike the Source Forge, and Google Code situation, it's more like an ethical version of Facebook taking over Myspace situation. GitLab stands a fighting chance.

We have to remember the Bevry mission and values here. Bevry can't say we want to "enable everyone to do what they love, share it with the entire world, and live well" something that is only possible with libre software, then promote and indirectly improve non-libre software through our actions — it would be hypocritical to what we are all about. Whenever there is a serious problem, it's best to acknowledge the concerns, work to counter them, and move on to something better — rather than let the concerns be an anchor to a situation we disagree with, hindering change and improvement. That's the risk factor in entrepreneurship, it's saying, yeah there's problems, but I think there's a shot at fixing them, only one way to find out.

It will be a move we'll document extensively. At least at this point, the classical pro cons raised in this discussion are:

Stay on GitHub
- Promote software ideology we disagree with
- Promote a premise of peer-pressure that is detrimental to diversity
- Gain more exposure perhaps — which is actually detrimental when that side-project requires full-time commitment
- Familiar workflow
Switch to GitLab
- Promote a software ideology we agree with
- Break the diversity shackles and embrace diversity
- Trade exposure of random consumers for a tighter smaller community aligned more with our values
- Good unfamiliar workflow, that will only get better the more people using it (this is only true, as they have a business that has funding, so more exposure does mean better results — we don't, but if we did, it would be equally beneficial regardless and irrelevant to which platform we are using)

hmm, you're probably right @balupton, i need to think about this more. is there a middle ground where we move some projects but not all? i'm keen to develop new projects like Interconnect on GitLab.

@dosire after consideration, this move only makes sense for new repos at this time. For existing repos it only makes sense if GitLab provides a import utility to mass import individual and organisation repositories including branches, issues, wiki, and team members - then update the github repo with a redirect page. You have my commitment that I will move all my personal projects over to GitLab if such a tool is created. Is such a tool something GitLab wishes to create?

@balupton I agree with you. It makes sense for new repos only. At least to make it a nicer transition for users.

It seems you can import repos:

2014-11-14-074110_1280x800_scrot

@balupton We're working on making the importer better (includes issues, etc.) and any contributions are of course welcome.

Still not possible to import projects with all metadata to Gitlab from Github?

@ToniNN Repo's and issues are imported. PR's https://gitlab.com/gitlab-org/gitlab-ce/issues/2833 and wiki's https://gitlab.com/gitlab-org/gitlab-ce/issues/2834 are planned.

bevry-archive / meta

Move everything to GitLab #15