But we're already here, doing those things, and every single one of the things that is listed as a problem is already fixed. Has no one used bitbucket or github and seen the completely ridiculous service tie-ins?
The reason forges are so insanely popular is because of not what they are, but where they are and how their presence lets the human mind feel a bit more at ease that there's a single place to go for a project for user and developer alike. They foster community, allow people to get started/involved, and fulfill a real human anthropological need when you're working on something completely intangible. Then DVCS came, and the wonders of web services. How has the forge itself coped? Look at Launchpad. You have the option of hosting one, some, or none of the traditional pieces of the puzzle and have optional commit hooks to completely useless services. Insert Bitbucket, Kenai, or Sourceforge in the place of Launchpad above, it's all the same. It breeds nothing but confusion for anyone looking from the outside in. Start hosting one or more service on one or more sites and it can be maddening. Forge lock-in isn't a problem, it's a symptom and minor annoyance in the end. But, we'll build thousands of RESTful services and abuse them all in unintended ways until we're till the 5th level of meta-api's instead of focusing on building a community. It's all about being popular now from what I understand. Although, I'm going to miss monolithic forges for the identity, sense of purpose, involvement they provided, hours of entertainment, and for the sheer wtf factor of finding completely ridiculous things in corners I never knew existed. On Wed, 2009-10-28 at 08:13 +0700, Michel Bauwens wrote: > Sam has published his comment on Eric Raymond's forge lock-in fears: > > (http://blog.p2pfoundation.net/forge-lock-in-is-not-the-problem-its-the-choices-that-people-make-that-is-the-problem/2009/10/27) > “Forge lock in” is not the problem. It’s the choices that people make, > that are the problem. > > photo of Sam Rose > Sam Rose > 27th October 2009 > > (the following is derived from ongoing conversation among Sam Rose, > Paul B Hartzog, Rick Adler, and Keith Smith [and probably others I am > currently forgetting about) > > At http://esr.ibiblio.org/?p=1282 Eric S. Raymond writes: > > The worst problem with almost all current hosting sites is > that they’re data jails. You can put data (the source code > revision history, mailing list address lists, bug reports) > into them, but getting a complete snapshot of that data back > out often ranges from painful to impossible. > > Why is this an issue? Very practically, because hosting sites, > even well-established ones, sometimes go off the air. Any > prudent project lead should be thinking about how to recover > if that happens, and how to take periodic backups of critical > project data. But more generally, it’s your data. You should > own it. If you can’t push a button and get a snapshot of your > project state out of the site whenever you want, you don’t own > it. > > When berlios.de crashed on me, I was lucky; I had been > preparing to migrate GPSD off the site due to deteriorating > performance; I had a Subversion dump file that was less than > two weeks old. I was able to bring that up to date by > translating commits from an unofficial git mirror. I was > doubly lucky in that the Mailman adminstrative (sic) pages > remained accessible even when the project webspace and > repositories had been 404 for two days. > > But actually retrieving my mailing-list data was a hideous > process that involved screen-scraping HTML by hand, and I had > no hope at all of retrieving the bug tracker state. > > This anecdote illustrates the most serious manifestations of > the data-jail problem. Third-generation version-control (hg, > git, bzr, etc.) systems pretty much solve it for code > repositories; every checkout is a mirror. But most projects > have two other critical data collections: their mailing-list > state and their bug-tracker state. And, on all sites I know of > in late 2009, those are seriously jailed. > > This is a problem that goes straight to the design of the > software subsystems used by these sites. Some are generic: of > these, the most frequent single offender is 2.x versions of > Mailman, the most widely used mailing-list manager (the > Mailman maintainers claim to have fixed this in 3.0). > Bug-trackers tend to be tightly tied to individual hosting > engines, and are even harder to dig data out of. > > > Eric acknowledges that distributed revision control solves the problem > of the code repository being a “data jail”. My opinion is that the > other problems are solved by extremely low cost hosting of your own > email lists (many shared hosting providers offers GNUMailman lists for > 5-10 per month) plus, hosting your own distributed bug tracking via > tools like http://bugseverywhere.org/be/show/HomePage > > It’s my opinion that the building blocks (and more than 90% of the > solutions) exist to route around the blockages caused by “forge > lock-in”. The distribution of communication could be done via > http://openmicroblogging.org/protocol/0.1/ which could allow people to > post to development discussions from almost anywhere online, and have > the messages tracked and linked to via microblog. This would obsolete > the need for email discussion of development altogether (a change I > would fully welcome). this could also synchronize with discussions > happening in IRC channels (where most developers now actually discuss > development these days anyway) . Tools already exist to connect IRC > with asynch online discussion. > > The conclusions that I draw: > > 1. “forge” sites have obsoleted themselves to being anything > other than a convenient mirror for project release files > 2. It’s more important to me to focus my time and energy on ways > to route around the blockage, than to decry the blockage, > especially when it’s now 100% possible and affordable for > people with even meager resources to route around > 3. Most importantly: many of the problems that are a concern (not > just with “forge lock-in”, but also with data lockin from > social media websites) can be easily solved now with > distributed solutions. The first question you should ask is: > “how will my activities and data interoperate with others?“, > and NOT “how will this best work for me?” if you concentrate > on how your approach will interoperate best with others, there > is still room to address how it will work best for you. But, > if you only concetrate on how your approach will work best for > you, you’ll miss opportunities by ignoring interoperability. > **INTEROPERABILITY IS THE FIRST PRIORITY** if you want to > avoid the later problems of “data jails”, “data lockin” etc. > Invest now in infrastructure that allows for expansion, > connection with others in a plurality of ways, and allows for > as much distribution of infrastructure as possible. This > investment will return to you exponentially, as you have > chosen infrastructure that is permenantly adaptable to new > standards, new pressures etc > > For anyone, not just developers, but also for people discussing > problems such as the problems with “crowdsourcing” and “locked social > media” discussed frequently at > https://mailman.thing.net/mailman/listinfo/idc : the choices that > *you* make, are what locks you in to the systems that you see are > constraining you. There are other choices that you can make now, and > they are worth the investment, but many are not making these choices. > > The same is true for how you structure collaboration. And/or, how you > participate in collaborative processes, how your “surplus labor” is > used. In all cases, before jumping in and using services run by > companies who’s primary and sometimes even legally required focus is > to seek monetary profit: spend the time looking at what the plausible > alternatives are, and design for interoperability and adaptability. > Give your money and resources to those people that already exist that > will give you solutions that won’t lock you in, and that will let you > adapt over time. Don’t always opt for the instant gratification > choice. There are people out there who can and will capitalize on your > need for instant gratification, then complain after the fact that the > choice you make made it harder for you to adapt and sustain your > activities over time. If you change your focus from “what is best for > me now” to “how I can make this activity as interoperable and flexibly > adaptable as possible”, you will not have the dilemma of having to > deal with “lock in” or leaching of “surplus labor” problems > > > > > > On Wed, Oct 28, 2009 at 1:41 AM, Benj. Mako Hill <[email protected]> > wrote: > I finally moved a bunch of stuff off the server that runs > autonomo.us > server and deactivated a stats plugin that seemed to be a > large part of > our sluggishness. Things seems to be much more responsive now. > > Get in contact with me directly if you notice other issues. > > Later, > Mako > > -- > Benjamin Mako Hill > [email protected] > http://mako.cc/ > > Creativity can be a social contribution, but only in so far > as society is free to use the results. --GNU Manifesto > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.9 (GNU/Linux) > > iEYEARECAAYFAkrnPsAACgkQic1LIWB1WeZ1vwCdGzRnRSp1T/fla > +93NhveOcOE > TSEAoMSNmJr6koUepBVx0qbNB6A4XnEk > =uPvd > -----END PGP SIGNATURE----- > > _______________________________________________ > Discuss mailing list > [email protected] > http://lists.autonomo.us/mailman/listinfo/discuss > > > > > -- > Work: http://en.wikipedia.org/wiki/Dhurakij_Pundit_University - > Research: http://www.dpu.ac.th/dpuic/info/Research.html - Think thank: > http://www.asianforesightinstitute.org/index.php/eng/The-AFI > > P2P Foundation: http://p2pfoundation.net - > http://blog.p2pfoundation.net > > Connect: http://p2pfoundation.ning.com; Discuss: > http://listcultures.org/mailman/listinfo/p2presearch_listcultures.org > > Updates: http://del.icio.us/mbauwens; http://friendfeed.com/mbauwens; > http://twitter.com/mbauwens; http://www.facebook.com/mbauwens > > > > > _______________________________________________ > Discuss mailing list > [email protected] > http://lists.autonomo.us/mailman/listinfo/discuss _______________________________________________ Discuss mailing list [email protected] http://lists.autonomo.us/mailman/listinfo/discuss
