Promoting open-source methods in large companies

The first keynote was on promoting open-source methods in large companies. Not using slides made it quite hard to follow, that made me realise how slide stacks help with understanding the structure of a talk, what was said when there is noise around, or just remember/understand where we're at after being distracted and having zoned out for a couple of minutes... (and let's be honest that's always going to happen!)

Brooks Davis described his journey getting open-source adopted internally. It was more in the sense of having people open-source their projects within the company than anything larger, although quite a lot of open-source projects were used to achieve that (Apache, PostgreSQL, trac...) He started from quite far since he had to sell people on the concept of version control itself to begin with! (I empathise with that, it's very hard to make devs who are not familiar with it  use version control tools to their full potential. For instance I keep having to remind my team that it's ok to delete a now-unused file or big chunk of code because we can find it again if we need to. Dead files and dead code just make maintenance more painful.) The policy they set out for their internal open-source repository was that ALL projects had to be ENTIRELY open-source (can't keep any section secret.)

The barriers to adoption were mostly driven by fear:

• Fear of misuse: People need to trust their colleagues! (This is actually an interesting point. The speaker works with space-related software so I'm guessing there's quite a lot of IP and other trade secrets in their software. I wonder how they ensure and/or convince management that no employee would sell them out to the competition. I understand how the policy is tremendously useful to avoid duplication, foster collaboration between internal projects and just make sure part of the project doesn't disappear or get lost with a single developer. It's possible the speaker talked about this and I missed it though, the keynote should have been recorded... I guess this point includes "trust your employees" as well.)
• Misplaced sense of ownership, with people believing "this is MY code" when actually, this is the COMPANY code!
• Credit: Although the open-source community is quite good at it, within a company people tend not to be so good at giving credit where it's due (although they are learning, according to the speaker!)
• Another concern was that "people will like it and then they will modify it and make it better," quite a confusing complaint

The positive points of this approach and policy are that:

• anyone can access the code in the public repository, rather than have it exist on only the one guy's laptop, that has to be hunted down when someone wants to reuse the code or needs it for another project
• there is a snowball effect once people start using the system

Along the way a few lessons were learnt and changes were made accordingly:

• The "everything must be open and available" policy was relaxed a bit to accommodate for NDA, work by contractors, etc. A project must submit an application to justify such security requirements, to be reviewed and approved (many teams believe their project require such mechanism when really, it doesn't)
• Moved from mod_python to wsgi (easier to manage)
• Performance: They bought more RAM to handle the multiple Python instances (1/project), and thanks to WSGI have the project sleep when not accessed (they still have issues with the internal search crawler though, as it means every project page gets accessed within a few seconds!)

The barriers to adoption by development teams are:

• Team isolation, each team kinda works in its own island
• People don't know it exists
• People think it's a heavy-weight project involving lots of paperwork (e.g. fill 6 forms to make a change)

There was a bit of talk on distributed version control. He finds it interesting but as his people are just getting used to the concept of centralised version control it might be a bit early. There is also the issue of backing up the projects, because the distributed nature of those tools could mean that people revert to only having a copy on their own machine. He's interested to see how people in open-source deal with this, and hopefully learn from it.

They are working on a few improvements to trac that they aim to contribute back (e.g. seeing tickets for multiple projects on the one screen.)

In the end I was a bit disappointed by the talk, because it focused so much on implementation (which is cool, I love hearing about this kind of stuff but I already had this with Ship It!. I know I want it.) when I was hoping for more strategies on how to help management and developers see the benefits of open-source. I'm interested in understanding how to get it adopted internally, how to bring change. Someone in the audience actually asked kind of a similar question, asking how he got management to pressure one particular internal project to use the new tools (mentioned during the talk.) I think the answer was along the lines of if the company spends a couple of millions a year on a project or another, they're interested in seeing it reused and easily available internally. Which doesn't really help us, but I guess if he has support from management to begin with it's just difficult to answer.

Evil on the Internet

The second morning keynote was about Evil on the Internet. The poor speaker, Richard Clayton, was severely booed at the beginning when the Windows screen showed up as people struggled to get Windows to play nice with the projector, but once he started with his talk it was most excellent because presented in such a funny way. Apparently the only thing bad guys have to do all day is design very nice and sleek looking websites, while trying to screw people over every possible way. To me the highlight of the talk was the job ad for Millenium Inc., a phishing company (though it doesn't present itself as such, for obvious reasons.) Their vacancies page advertises for a lot of positions, most them "not currently available" ...except for one. They are looking for a "payment processing assistant." Your job would consist of receiving payments from their clients onto your bank account, that you then take out and send on to Millenium through Western Union. Very nice. When the bank realises the money was moved onto your account through fraud it will take it away, and you'll be left with no recourse because Western Union will never ever refund any money you send using their services. There were many other examples, and there's more on his blog.