Recently we held a 3-day-long Python sprint in Budapest before the RuPy conference. Here's what got done.
Substance D (web application server)
Participating: Chris McDonough, Balázs Reé, Godefroid Chapelle
- Allow management views to be categorized.
- Allow deletion of objects that cannot successfully be unpickled.
- Add an API for get_editable_adapter.
- Allow schemas that inherit from substanced.schema.Schema to be used successfully in non-FormView code (no longer necessary to call .bind() on these to run things through deserialization).
- Grid error messages caused by connectivity problems now disappear if the client notices that the server is back up via SSE.
- Attempted to figure out how to more better show "global" views (like the auditing tab, the database tab, and the undo tab).
- Various small UI improvements.
Deform (form library)
Participating: Domen Kožar, Balázs Reé, Chris McDonough
- Experimented with using angular.js for client-side validation (fairly successfully).
- Refactored and improved resource registry.
Pyramid (web framework)
Participating: Fabian Neumann
- Audit docs for places we could better use .. deprecated:: and other Sphinx/RST directives.
This story is about how the practice we call "sprinting" in the Zope / Python ecosphere came to be.
What is a "Sprint"?
As used by Zope and Python folks, a "sprint" is an intensely focused session, usually lasting less than a week, in which a group of developers work together to design and implement features for a library / framework application. Many conferences now host sprinting in the days before or after the conference proper, but there are also lots of sprints which occur outside of any conference.
Where did the term come from?
Back in the fall of 2001, I had my first (and only) performance review at Zope Corporation (then Digital Creations). As part of the review, Jim Fulton asked if there were any changes I would like to see in the way the company developed software. At that point, the official process we used was pretty heavy, with lots of "Big Design Up Front" artifacts.
I had been following Extreme Programming (XP) via the "mother-of-all-wikis" since the mid 1990s. I suggested that it would be good to find a way to experiment with some of the practices of XP, but in a way that wouldn't involve making a big committment to the whole discipline. We were in the early stages of re-writing the Zope application server, and decided that we would hold a short, in-house session (four days), where we would consciously attempt to apply as many of the XP practices as seemed feasible while working on the next-generation Zope.
Because we had only a short time to experiment, but still wanted to achieve a significant delivery milestone, one of the XP values we didn't embrace was the notion of software development as "long-distance running" (no overtime, etc.) We therefore began to refer to the upcoming experiment as a "sprint".
Scrum, a different "agile" methodology from XP, used the term "sprint" to refer to a month-long development increment. I was only lightly aware of Scrum at the time, and wan't (consciously, at least) borrowing the term.
The goal of that initial sprint was to (re-)implement the "Interface" package, which prototyped the PEP 245 interface semantics (but not syntax) for Zope2. The new package we built, zope.interface, is still the core of the component architecture today, and is used by projects such as Twisted and Pyramid
The results of that first trial was terrific: we found that the practices we applied (pair-programming, test-driven development, YAGNI) led to a very productive outcome. More imporant, we found that the four participants left with a much stronger understanding of the design of the software we had built, and were therefore much better able to keep working on the code separately.
Sprints as Evangelism
Reviewing the successes of the first, in-house sprint, we wanted to find ways to repeat the process. In January of 2002, we were trying to design a new, in-core mechanism for translating software-generated text (from templates and Python code, rather than user-entered content). We came up with the notion of invitng the authors of the main Zope2 i18n/l10n products (Stephan Richter's ZBabel and Juan David Polomar's Localizer) to ZC for an "i18n sprint".
As we had hoped, this sprint laid the technical foundations for the i18n support in Zope-related code to this day. Beyond our imagining, however, was the impact the sprint had on the non-ZC sprinters: they were fired up about the new technology, and were able to go back to their own communities and rally support for it. Indeed, one of those sprinters, Stephan Richter, went on to write the first Zope3 book: he is still active in the Zope software world to this date.
From that experience of the social/organizational benefits of sprinting, we began scheduling sprints to take advantage of participants expertise and interest in the new Zope software, and were thus able to expand the committer base to 400+ committers over the next three years.
Until fairly recently, it was pretty common for a custom software development company to sign a contract to build software with an indemnification clause not unlike this one:
Indemnification. Vendor agrees to indemnify, hold harmless, and at BigCo’s option defend BigCo and its subsidiaries, affiliates, and their respective officers, directors, employees, agents, contractors, successors and assigns (collectively, the “BigCo Indemnitees”), from any and all claims and all related losses, liabilities, damages, costs and expenses (including, without limitation, reasonable legal fees and disbursements and costs of investigation, litigation, settlement, judgment, interest and penalties) (collectively, “Losses”) arising from or related to: (a) any allegation that the Deliverables, Vendor Materials, or Services: (i) violate or in any way infringe or misappropriate any third party’s patent, copyright, trademark, trade secret or other intellectual property right, (ii) violate any applicable law, rule or regulation, or (iii) constitute, or contain material that constitutes, libel, defamation or a violation of the right of privacy or publicity; and (b) any claim that is based, in whole or in part, on any act or omission of Vendor (or any of Vendor’s Personnel). These indemnification provisions shall be conditioned upon Vendor not consenting to any judgment or decree or entering into any settlement of such action without BigCo’s prior written approval.
In the minds of many US corporate lawyers, it would show bad faith for a consulting company to object to a clause like the above. It would indicate that either a) the consulting company was twirling their metaphorical mustaches, planning to lazily inject clearly stolen, patent-tainted intellectual property into software they're instead being paid good money to write from scratch or b) the consulting company was planning to at very least bill for more hours than they worked, reusing existing -- possibly patentable -- code they did not own, left over from other consulting work. Either way, a corporate lawyer might argue, this consulting company is clearly not looking out for BigCo's best interests. If they were, they'd just sign the contract with the indemnification clause intact. After all, the consulting company would clearly be at fault in such a case, and an honest company wouldn't provide patent-infringing code in the first place! Just what kind of scam this Agendaless company trying to pull, anyway?
Even though we risk such "bad faith" claims, Agendaless does not sign contracts with such clauses in them unmodified. If we receive a contract with such language, we ask for the clause to be stricken. If it cannot be stricken, we ask for the clause to contain limiting language such as a upper bound on damages below the value of the contract, or a specific list of patents that we must not infringe, or a limitation specifying willfulness of infringement. And if that doesn't work, to our dismay and to the dismay of the folks at BigCo who want the work done, we'll turn the contract down. This is likely to be true no matter how small or how large the contract is.
You might ask: why would we, at the very birth of a project -- the exquisitely beautiful union of two corporate entities -- want to poison the well like this? It seems like craziness!
Two words: patent trolls. A nicer term for a patent troll is a "Non-Practicing Entity" or "NPE". From http://blog.tridentcap.com/2011/11/ip-alert-time-to-reexamine-patent-indemnification-clauses.html
An NPE is an entity that owns patent rights but has no material business operations of its own. Many NPEs acquire patents for the sole purpose of generating license revenue through litigation or threat of litigation. The NPE has no operations that can give rise to any counterclaims, and therefore there is little to no business pressure the defendant can bring to bear to encourage settlement. Given that NPEs are counter-claim proof, it serves their interests to sue every company with business operations in a given sector, and they have little to no incentive to settle without extracting significant monetary value.
In other words, almost literally, patent trolls really are trolls. But instead of collecting tolls for a physical bridge they don't actually own, they sit underneath a metaphorical bridge waiting for you to infringe upon their "intellectual property". This is their entire business model. They sue whomever they can, casting a shakedown net far and wide against companies that had no prior knowledge that they were violating any patent, betting that many companies will be willing to settle rather than spend money on legal fees to defend against their claims. They don't actually produce anything based on their patents, their patents are only used as a litigation tool.
Patent trolls obtain patents by buying them from other legal entities. Since patents in the US are granted seemingly by people who have absolutely no idea what they're granting, they are comically overbroad. For example, here's an excerpt from a patent granted by the US PTO (Patent and Trademark Office) entitled "Method for making money on the Internet" (http://www.google.com/patents/US8296192) filed in June of 2009:
A computer-implemented system for monetizing internet content. The system includes an internet content provider providing online information on a web page and an online comment section associated with said online information, said online comment section capable of having posted thereto reader comments in a free default format. The system includes computer executable instructions for performing steps of displaying an offer associated with said online information to alter a reader comment from a free default format to a distinctive format for a fee, said fee being dynamically adjustable; receiving by the internet content provider; and displaying the reader comment in the distinctive format on the web page. The system also includes a processor for executing the computer executable instructions, and a memory for storing at least the computer executable instructions.
If your eyes glazed over trying to read that, you are in good company. The language it employs is complete nonsense, and could be interpreted to mean just about anything. The rest of the patent isn't much more informative. It's basically total gibberish, with no actual useful technical information. But it claims to own the idea of making money on the internet, and it is a valid patent that has actually, in reality, in this real world in which we live, been granted to an entity. On Earth.
And who do you think owns that patent currently? Amazon? Google? Microsoft? No. The person that owns that patent is likely indeed, by all available evidence, such an NPE. It's a lawyer named Roddy McKee from Milford OH. That entity apparently has another patent in the works entitled "Universal one-click online payment method and system" http://www.faqs.org/patents/app/20100332337 . I'd wager a guess that Roddy McKee can't fix his Outlook when it breaks, much less design and operate grand systems such as those described by his patents and patents-pending. Delicious, right?
There are thousands of such entities in the US, and tens of thousands of such overbroad patents granted to seemingly anyone who can write enough technojargon to befuddle the USPTO. In 2012, more than half of patent litigation cases filed in the U.S. were filed by NPEs (http://www.law.com/corporatecounsel/PubArticleCC.jsp?id=1202595510252&Majority_of_2012_Patent_Litigation_Filed_by_Patent_Trolls&slreturn=20130706192341). From the same article: "Of the 10 most frequent patent litigation filers, nine were patent monetizers and only one was a company making products, the study revealed."
The indemnification clause above exposes Agendaless to unbounded liability from such patent trolls. If a patent troll were to sue BigCo claiming that code we licensed to them under the terms of an associated contract infringed on one of the patents in their stable, the language in the contract above exposes us to "any and all claims and all related losses, liabilities, damages, costs and expenses (including, without limitation, reasonable legal fees and disbursements and costs of investigation, litigation, settlement, judgment, interest and penalties) (collectively, “Losses”)". Emphasis mine.
In software patent cases, such "losses", however imaginary, by patent trolls can add up to millions of dollars. Without taking damages into account, even if we were to "win" such a case, the legal costs alone, and time spent not billing on other projects would put Agendaless out of business many times over. According to https://en.wikipedia.org/wiki/Patent_troll "the cost of defending against a patent infringement suit as of 2004 is typically $1 million or more before trial and $2.5 million for a complete defense, even if successful." So, it's no wonder, that many would choose to settle instead. From http://arstechnica.com/tech-policy/2012/07/new-study-same-authors-patent-trolls-cost-economy-29-billion-yearly/: "the median amount spent to pay off a troll suit is ... $230,000 for large companies". This same article, however, indicates that the mean value to pay off a troll lawsuit for large companies is $7.27 million dollars. So win or lose, you lose.
Given the current software patent landscape, blanket indemnification is therefore a risk too great for us to assume. Agendaless is a company with historical gross earnings of fewer than a million dollars per year. We write many thousands of lines of code every year. It would be financially crippling to need to figure out if some line of code, or some integration of many lines of code violated any US patent, especially when most software patents are so ridiculously overbroad. It would take an astromonical amount of time to do due diligence: we'd never actually deliver anything in a reasonable amount of time and every project would cost a prohibitive amount of money. It is not a task that can be accomplished.
But even so, if somehow magically we could always know in some reasonable amount of time when we were violating some patent with some bit of code or some integration, what would we do when we did ? Would we stop development of the system? How would the customer feel about such a situation? "Sorry, we had to stop writing your system because it might infringe on this ridiculous patent." Would the customer just say "oh ok, then, I guess you don't need to deliver the software then." Unlikely. We'd almost certainly be asked to deliver something anyway. No one could actually know how to proceed on such a project. There will almost certainly be rework involved. Who pays for the rework? How long is it going to take? Will it still be on time? It's a minefield of liability, even without getting sued.
As a result, as a custom software development company, we just need to assume that code we write violates some crazy patent somewhere, and we hope for the best. The same is true of any US-based consulting firm. Every line of code written by every programmer on the planet (or at least in the US), every website propped up by every company, is a potential target for frivolous and crippling litigation. And there is virtually no defense, except at very least to avoid blanket-indemnifying other parties, to the same extent that you can avoid getting a black eye by avoiding inviting someone to punch you in the face. So it's not out of bad faith that we choose to not blanket-indemnify. It's purely out of self-preservation. By the way, we'd love to be indemnified ourselves! Our current self-indemnification strategy is to have very little in holdings. Patent trolls don't sue people without money. It's a terrible strategy, but it's the only one we have.
Any small- or medium-sized US-based consulting firm that signs a contract with an unbounded patent indemnification clause in it is taking an extreme risk. They will almost certainly be put out of business at the first whiff of litigation.
Lawmakers are supposedly trying to fix this mess through things like the cutely-named SHIELD Act ("Saving High-Tech Innovators from Egregious Legal Disputes Act"). And reportedly some states such as Vermont are offering high-tech businesses some vague protection against patent troll suits. But as of right now, there's no true solution in sight other than protecting ourselves by limiting our liability.
In the meantime, something makes patent infringement language negotiations truly interesting for Agendaless in particular. We almost never enter into a consulting engagement where the customer doesn't already use at least some of our software, and is therefore already implicitly a licensee of ours on other terms. This is because we create and publish open source software, and -- by and large -- customers usually engage us as consultants as a result of having already put into production some of that software. Our standard open source license, like many others, (http://repoze.org/LICENSE.txt) is very simple, but it does have an explicit non-indemnification clause in it, or at least we interpret it as such (the "Disclaimer"). Typically, if they have our open source software in production, this is the license that customers have agreed to, under which they are already consuming our software.
As a result, we've found ourselves in some pretty comical situations. We've needed to negotiate with lawyers for hours, agonizing over patent infringement clause wording that will end up covering perhaps 500 lines of code as part of a minor customization job that might net us a few thousand dollars. In the meantime, we'll know that the company which the lawyer represents already has, in production, hundreds of thousands of lines of related code that we've produced. The company has been using this body of code under our standard open source license to run some core element of their business. This code will have always been put into production long before any Agendaless people might become in-the-flesh-involved. And using the logic of the contract clause we now must negotiate, we can only assume that the customer is, has been, and will continue to be highly exposed to a patent infringement suit that identifies some functionality of this large body of unindemnified code. But nevermind that! Now that there's an opportunity to have a ceremony involving an actual paper contract, it makes sense that a blanket patent indemnity for some relatively obscure body of code that is orders of magnitude smaller than what already exists unindemnified in production should become critically important. That's sarcasm, by the way.
If you want to get particularly indignant about patent trolling, you can listen to Ira Glass' This American Life episode called When Patents Attack! http://www.thisamericanlife.org/radio-archives/episode/441/when-patents-attack . It's a reasonably easy and "fun" way to learn about the wild world of software patents. Just be sure to keep any sharp objects out of reach while listening.
Who ever said the business side of software consulting was not interesting?