SourceForge: Sanctions or Sieve?

It seems that SourceForge has recently started limiting access to users in countries that are on the US sanction list.

SourceForge explained their reasoning for this move in a recent blog post.  Summarized: It's The Law.  Companies who don't follow the law quickly run into The Man and always regret it.

This logic is fairly impeccable to me.  No, that does not mean that I condone the limiting of information of any sort—but particularly not Open Source or Creative Commons information—to anyone in any country.  In fact I find the idea fairly repugnant.  That said, flaunting a law is no way to change it.  SourceForge, as a company operating in the United States, had no choice in the matter.

It's unfortunate that this situation won't hurt the decision makers of these countries.  Innocent geeks are being punished for events entirely out of their control.  Or are they?

The fact of the matter is this: Iranian, Cuban, North Korean or North Dakotan: a geek is a geek.  We're a resourceful bunch and a diligent.  The open nature of the information maintained at SourceForge means that it can undoubtedly be found elsewhere on the net.  And if it can't?  Well, there are any number of options out there for industrious people to bypass these limitations.

Yes, it sucks that SourceForge had to do this.  Yet in the great grand scheme of things this particular sanction doesn't appear to hold very much water.  Hopefully the SourceForge team realized this and were able to feel just a little less crappy for having to implement it.

Topics to consider for Perl 6 newbies

As a newbie to Perl 6 and contributing to Open Source projects I have a decent perspective on the questions that arise when starting out on this path but it's still an informed perspective. My day job is Cat Herder in Residence (aka Director of Product Development) for a small but spunky software company in the Bay Area, CA. This, one would hope, gives me a pretty good foundation for how software projects can run, so I'm not starting entirely from zero.

However there are plenty of smart and ambitious people out there who are starting from zero. Face it: none of us (not even Larry himself) was born with a priori knowledge of how to work on a project. At some point we were all starting at zero. At some point you asked someone or did enough digging to figure out what's going on. Or, more likely, at some point you just dove in, screwed up, got scolded and learned a valuable lesson. Those of us who've learned some of these lessons undoubtedly take it for granted. Actions and answers become rote, their delivery confident but their sources lost in the mists of time.

This can cause even seemingly mundane tasks to appear intimidating to a true newbie. Some will take the plunge and make the mistakes, but many won't. Many well-intentioned good people who have much to contribute will turn away because the process appears opaque. It doesn't have to be like that. The people of Perl 6 are open and welcoming so why shouldn't the process be as well? It shouldn't just be all about pointing people at the code and sending them on their merry (if potentially clueless) way.

So what things would a total newbie need to know when coming into Perl 6 or any other Open Source project? What questions should they ask (but maybe not know to)? In no particular order and off the top of my head I've come up with these:

• Issue Tracking
• Documentation
• Help
• Source Control
• Coding Style Guide/Tips
• Programming Language(s)
• Testing
• Project Plan/Roadmap
• Culture
• Etiquette
• Acronyms

It's unlikely that this is a complete list. Also, this list isn't meant to imply that Perl 6 information doesn't already exist on these topics out there on the wild wild web. Undoubtedly it does but it may be scattered. I admit that I haven't researched to that level...yet. My intention is to try to start the effort of gathering this information into one spot: here. I'll be moving it to a more public location as soon as possible to make it easier to find and so others may help add to it.

Your homework: tell me what topics I've missed.

Too many ways to do it

When starting a project it's best to read up a bit. Hitting the tubes I found that this is easier said than done. My brief search turned up a number of websites, all of which may or may not be canonical:

• Perl 6 at dev.perl.org
• Perl 6 at Perl Foundation
• perl6.org
• rakudo.org
• parrot.org
• pugscode.org
• ...

So...um...huh? Where's a gal supposed to start? I assumed that perl6.org would be the place to be but it just didn't feel right. So I found my way to dev.perl.org, hoping to find more guidance there. No...that's not working either. Perl Foundation? Um...a little better...I think. If nothing else I can at least fix some broken links in the wiki...

I've since heard from a friend that rakudo.org is the happening place in the Perl 6 community. How in the hell a person is supposed to know that without a guide is entirely beyond me. I mean, you'd think at least one of the "top level" Perl 6 sites (why so many? Why? Why not have just one and all the others point to it?) would have said "Go there. Start at rakudo."

Heck, a simple, "Go there. Start by reading The Spec" or something similarly useful would be nice.

So, no, I still don't know how/where this path starts. But I'm not giving up yet so, hey, Allons-y!.

Contributing to OS: Project Selected...Perl 6

This evening I made my first forays into contributing to an OS project.  My project of choice is Perl 6.  Why?

• I know (but am not expert at) Perl 5
• Perl 6 is new(-ish) and original
• This will give me a chance to learn new things but framed in a somewhat familiar context
• I have a Perl-shaped soft spot in my heart

I'll be using this blog to document my exciting forays into the sometimes-chaotic world of OS contribution.