Response: Speeds and Feeds › Of Money, Responsibility, and Pride

Steve Marquess who manages the business side of the OpenSSL Foundation talks about the shabby state of corporate support for open source development.

I want to call out this paragraph first (although many other are more interesting), about the courage and discipline it takes to publish your work in the face of fear of public scrutiny:

I stand in awe of their talent and dedication, that of Stephen Henson in particular. It takes nerves of steel to work for many years on hundreds of thousands of lines of very complex code, with every line of code you touch visible to the world, knowing that code is used by banks, firewalls, weapons systems, web sites, smart phones, industry, government, everywhere. Knowing that you’ll be ignored and unappreciated until something goes wrong. The combination of the personality to handle that kind of pressure with the relevant technical skills and experience to effectively work on such software is a rare commodity, and those who have it are likely to already be a valued, well-rewarded, and jealously guarded resource of some company or worthy cause. For those reasons OpenSSL will always be undermanned, but the present situation can and should be improved.

I agree strongly with this. It does take confidence & courage to overcome the fear of public criticism.

This line is particularly damning of companies. Turns out that only one developer is full time working on OpenSSL, everyone else is part-time.

While OpenSSL does “belong to the people” it is neither realistic nor appropriate to expect that a few hundred, or even a few thousand, individuals provide all the financial support. The ones who should be contributing real resources are the commercial companies[5] and governments[6] who use OpenSSL extensively and take it for granted.

It’s also true that people in companies find it hard to raise purchase orders. ITIL-compliant Project Managers using ITSM would never pay for anything that can be avoided. The sort of enlightenment that is need to support an open source project is beyond ITIL concepts.

The call to action is buried in the footnotes:

I said legal and moral; shameless still goes so here’s a plug for one of the most effective ways your corporation can not only support OpenSSL but also receive something of tangible value in return: a software support contract. We have a formal contract with the fine print that lawyers love, and your accounts payable people won’t be all flummoxed at the bizarre notion of giving money away as they’re used to paying for expensive commercial support contracts for proprietary software. Someday you may even encounter an issue with your mission critical use of OpenSSL that could benefit from direct and prompt attention from the people who wrote that code.

What can we do to get companies to contribute small amounts of money to open source projects like OpenSSL ?

via Speeds and Feeds › Of Money, Responsibility, and Pride.

  • returnofthemus

    LMAO, though I do feel we are at least starting to make some progress!

    In a previous installment we learned that ITIL couldn’t be relied upon to determine which optics to use for a particular brand of switch, however it could’ve been used to measure the overall value of an installation project, providing that SMEs were on hand for guidence.

    Today we have learned that ITIL can’t be relied upon to solve the problem of poor coding practice, cannot identify flawed code or have any influence over how flawed code gets implemented, essentiallly this is because ITIL is the ‘Ops’ and not the ‘Dev’ in DevOps. The likely role that ITIL is playing here is in incident response.

    We’ve all heard the business calls for more speed and agility, which in turn has led to newfangled methodologies like Agile (Project Management), Lean (Six Sigma), Kanban, Scrum etc, leading to phrases such as, ‘fail fast, fail often’, where QA appears to get thrown out the window.

    Should we really be surprised by this recent OpenSSL debacle?