Archive for the ‘open source’ Category

Predicting FOSS Fail

Monday, March 1st, 2010

The Open Source Way is a great resource for developers who want to start their own open source project. It is a wiki of lessons learned and best practices gathered primarily from experiences working on the RedHat and Fedora projects. One page that I find particularly interesting is “How to tell if a FLOSS project is doomed to FAIL.” The format assigns “fail points” for common (and uncommonly stupid) mistakes that project leads make. Making a few of these mistakes doesn’t doom your project but making lots of them definitely stacks the odds against you.

While it was written from the perspective of a Linux library developer, the list also contains useful information for other types of open source projects. I was hoping to add some content around project leadership but I was discouraged to see that I was not able to create an account or contribute to the discussion page (FAIL!). Here is what I would have added:

  • There is no road map showing planned improvements to the software
  • The project leader(s) is(/are) not transparent about decisions [ +5 points of fail ]
  • There are no guidelines for contributing to the project [ +20 points of fail ]
  • The project does not have a way to attract and incorporate new contributors [ +10 points of fail ]
  • The project does not have a system for recognizing/rewarding contributions [ +5 points of fail ]

Community Development

Monday, January 4th, 2010

I have finally gotten around to reading Clay Shirky’s excellent book Here Comes Everybody. I love Clay’s writing style and the way his perspectives make me think. One of the points that really resonated with me was about open source. But before I get into it, I should say that when Clay talks about open source, he is really talking about community developed open source (not commercial or institutional open source). Readers of this blog know that the designation “open source” simply means that it is licensed under an OSI certified license. “Open source” says nothing about how the software was developed. Given that disclaimer, Clay nails it when he describes the advantage of community developed software:

The bulk of open source projects fail, and most of the remaining successes are quite modest. But does that mean the threat from open systems generally is overrated and the commercial software industry can breathe easy? Here the answer is no. Open source is a profound threat, not because the open source ecosystem is outsuccessing commercial efforts but because it is outfailing them. Because the open source ecosystem, and by extension open social ecosystems generally, rely on peer production, the work on those systems can be considerably more experimental at a considerable less cost, than any firm can afford. (from page 245 of the hard cover version)

This quote comes from a chapter called “Failure for Free” that discusses the importance of failure for innovation. The key point is that traditional companies can’t afford to really innovate because they must limit their bets to initiatives that they feel have a high likelihood of success. Innovation winds up being constrained to small tweaks to things that are well known. Real breakthroughs are rare. Community development doesn’t make better ideas but it reduces the cost (and risk) of trying ideas that at first seem unlikely to succeed. Out of all this experimentation comes unexpected successes. Even the failures provide useful data that can be turned into future successes.

When open source critics see the volume of incomplete or dead open source projects as evidence against the sustainability of open source, they are missing the point. A low success rate is critical to real innovation; but that is hard to understand by someone for whom failure is discouraged or not tolerated at all. It is widely accepted that the best design for an experiment is one with a 50% chance of failure: if you know what the outcome will be, the experiment is not worth doing. But if the cost (in time and resources) of the experiment is zero or close to it, the ideal failure rate is much higher.

While we have seen many examples of community developed software out-innovating its commercial peers, this phenomenon has very little to do with open source. An open source license can create an environment that invites contribution by reducing the risk that one will exploit and unduly profit from another’s contribution. But what is more important is how the software is managed. Most successful open source projects have adopted an architecture consisting of a core that is tightly managed for stability and quality and is extensible by adding modules. The bar for module code is considerably lower than core code. This allows an open and dynamic community to experiment with new ideas. The community not only bears the cost of failure but it also brings in new perspectives that the core maintainers don’t have. Some of these extensions will be absorbed into the core or will become part of a commonly used bundle. Others will wither and die.

This pattern of stable core and innovative fringe does not have to be unique to open source. It doesn’t really matter how the core is licensed if entry into the fringe is open. The one area that open source licensing helps with the core is in achieving a level of ubiquity that attracts a community. High licensing fees or the bottleneck of a traditional software sales process can limit the size of the user base and discourage contribution. The community developer needs the promise of a large user base to justify the time investment of contributing his work. But open source is not the only way to achieve a large user base and there are plenty of examples of commercial software and SaaS user communities that have a successful code sharing ecosystem. One company that is particularly successful is Salesforce.com. Salesforce has created a very powerful API and module packaging framework. More importantly, they have priced the product to penetrate small-medium sized companies and non-profits. In particular, the Salesforce Foundation makes the product very inexpensive for non-profits. These strategies have infused the customer population with lots companies that are highly motivated to share. These customers are active both within the AppExchange community and also integrating 3rd party open source projects like Plone (see Plone/Salesforce Integration) and Drupal (see Salesforce module).

On the flip side, there are plenty of commercial open source software companies that not been able to leverage community development. There are two primary ways an open source software product can prevent community development from flourishing. First, there can be factors that limit adoption of the core like in the case of open core products that discourage the use of the open source version. Second, the architecture can be monolithic so the only way for an outsider to add a feature is to fork the codebase. All a software producer has to do is solve those two problems. The supplier doesn’t even really need to provide tools for sharing code. If the install base is large (which usually means the software is useful) and the architecture is modular, developers will find a way to communicate and share code. They can use services like Google Code, GitHub, or SourceForge to collaborate. Too often companies put code sharing tools in place without solving those two problems and then complain when they don’t see any activity. In many cases, the user audience is too small to support a contributing ecosystem. In other cases, the incentives are not lined up appropriately. Shirky calls the three ingredients of a collaborative community: promise, tools, and bargain. The promise is what the contributor can expect to get out of participating; the bargain is the terms and rules for participating. Open source licensing helps with the promise and the bargain. The open source promise is that others may help improve your code. The open source bargain is that people can’t take exclusive ownership and profit from your work. Some communities, like Salesforce and Joomla! have thriving commercial extension marketplaces. In those cases the promise and bargain are different but they are very motivating.

Any widely used software application, if it is appropriately designed, can benefit from community development and the benefits are not limited to the successful contributions. Perhaps the biggest value of community development is increased innovation through reducing the cost of failure. In order to harvest this value, a company needs to actively monitor, analyze and participate in its community. There is a goldmine of information sitting in the chaff of failed contributions as well as the modules that do gain traction. Companies that ignore this value do so at their own peril.

Presentations from the Boston Gilbane Conference

Friday, December 4th, 2009

I am catching up from a whirlwind of activity at the Gilbane Conference in Boston this week. I gave three presentations (below), organized a breakfast for open source CMS software executives, and had a great time talking with so many industry friends. It was particularly nice to meet people like Scott Liewehr (@sliewehr), Scott Paley (@spaley), Jeffrey MacIntyre (@jeffmacintyre), and Lars Trieloff (@trieloff) who I had known only virtually before. I wished I could have stayed for the third day of the conference but I had to get back to work. Everyone seemed to feel very positive about business and where content management is going so I left brimming with enthusiasm for 2010.

What follows is a brief run through of the presentations I gave.

Open Source WCM and Standards

On Tuesday morning, I did a presentation called Open Source WCM and Standards for the CMS Professionals Summit. To summarize, open source really has nothing to do with open standards but there are some areas where they converge. “Open source” describes a license. Any software can be open source if it is assigned an OSI-compliant license. Open standards is about software design — technology choices about what standards to support. That said, there are three areas where open source and open standards converge:

  • when an open source project is started to create a reference implementation for an emerging standard (note, on slide 5 I didn’t say that Alfresco was created as a reference implementation for CMIS, you had to be there.);
  • when there is a chicken and egg problem of value and adoption (like RSS and now RDF) some open source projects have the install base to easily create widespread support and a lower hurdle create an implementation;
  • projects driven by developers tend to put a higher priority on aspects like integration and attention to technical detail than marketing driven products which are more feature oriented.

How to Select a WCMS

My “How to select a WCMS” workshop is turning into a signature presentation for me. There was not too much difference from prior presentations of this workshop except this time I went into more detail on using doubt to make a decision. At that time, my friend Tim McLaughlin, from Siteworx, had popped into the room. He told me afterwards that he agrees with the approach and even read a scientific paper that found that the best decision makers use this method of elimination for choosing. Tim, if you are reading this, you owe me that link!

One particularly interesting part of that worshop was that one of the audience doubted the necessity of content management systems in general. So I was put into the position of having to defend the industry. He was coming from an organization that was managing 100 very small, unique, independently managed, and unimportant websites. In this case, I had to agree and I used the metaphor of a factory. You don’t build a factory to produce less than 10 units. A CMS would not help him until he started to try to manage all those websites in a more uniform way. For the time being, I suggested that he look into Adobe Contribute which handles basic things like deployment and library services without trying to manage reusable content.

Open Source: what’s it to you?

I presented with Kathleen Reidy from The 451 Group on “The rise of Open Source WCM.” Kathleen had some great slides talking about commercial open source vendors in the market. My presentation was from a buyer and implementer perspective. The general message was that buyers have the benefit of more choices and more information but they also have the responsibility to take a more active approach to selection. They can’t expect an analyst firm or salesman to tell them what is the best product. They need to understand their requirements and implement a solution that solves their business problems. Open source software suppliers depend on customers doing more pre-sales work themselves and they pass that savings back in the form of no (or low) licensing fees.

The biggest disappointment was when Deane Barker misunderstood slide 5 and tweeted that I think that open source is like a free puppy. Of course, this was re-tweeted several times. As I have said, all CMSs are like puppies: some are free, some cost lots of money, but all require care and feeding. If you have the intention of owning a puppy and understand the costs involved, you appreciate that a free puppy is less expensive than a puppy that you have to buy. If you spontaneously come home with a a puppy just because it was free, you might be in for an unpleasant surprise. Similarly, if you adopt a CMS just because it is free and you have not budgeted for properly implementing a website, you will get into yourself into trouble. Later, Deane and I had a great dinner together with David Hobbs before I headed back home.

Open Core

Wednesday, October 14th, 2009

In case you have not been following the open source blogosphere, there is an interesting discussion happening around a new term called “open core.” Open core describes the strategy of building a business on selling commercially licensed software with open source licensed components or companion products. Open core companies tend to use third party open source components and distribute some of their own components (not the complete solution) under an open source license (typically the GPL because that is the most protective). Matthew Aslett has a nice breakdown of what is and what isn’t open core; although I disagree that the subscription model is open core when the vendor requires a subscription fee to use the software.

This strategy is in contrast to software companies that primarily offer a free open source version of their product and make their revenue entirely from support services (such as technical support, maintenance, training, implementation). eZ Publish and Hippo are pretty good examples of pure open source companies. The term “open core” was coined by Andrew Lampitt and all the chatter around it shows how much it is needed. The market needed something to distinguish the two types of companies: open source and open core. Nicholas Goodman makes the observation that it doesn’t make sense for a company that only sells proprietary software to call itself an open source software company. Now each type of company gets its own descriptive classification.

Many of the “household name” open source software companies follow the open core model: Alfresco, SugarCRM, Pentaho, Magnolia… to name a few. The viability of the open source version varies from company to company. Magnolia Community, for example, is full featured enough for most typical uses and is as well maintained as the Enterprise Edition. In other cases, the Community Edition is deliberately hobbled to encourage an up-sell. In other cases, the licensing is just confusing. For example, Alfresco’s Enterprise Edition is officially GPL licensed but you need to pay an annual subscription fee to use the copy that was compiled and tested by Alfresco, Inc. — and they won’t sell you support or allow their partners help you unless you are using the version they compiled.

From a market perspective, the “open” companies that were established with venture capital tend to be open core. This makes sense because venture capitalists make big investments and are looking for big returns — bigger than what a pure services company can hope for. To get VC money, a start-up would have to position itself as a software company that needed to build product with scalable sales and decent margins downstream. Services companies don’t work that way. A services company can make money from day one but shouldn’t expect hockey stick growth and low variable costs. A successful service-based software company may also need huge market penetration to create a big enough market to sell services into. It is a matter of multiples. If for every 100 users you get 1 paying customer, you better have millions of users. Many software categories do not have that market potential. For every 1 CRM instance, a large company will probably have 3 CMS instances, 30 database instances, 60 web server instances, and 100 operating system instances. This is why RedHat can be more open to unpaid use than SugarCRM.

So, what does this all mean to the buyer? As I mentioned in the Open Source Web Content Management in Java Report, it is important to understand the vendor’s business model to judge the viability of the company and the total cost of the software that you will bear. Differentiating between open source and open core will add some clarity to a confusing marketplace with complicated licensing models.

Eric Barroca Debunking Commercial Open Source Myths

Wednesday, August 12th, 2009

Nuxeo CEO Éric Barroca has an excellent post that breaks down the hype and decodes the marketing speak around commercial open source software. He doesn’t name names but he does call out some of the claims and language of some commercial open source vendors. The general message is this: software vendors should focus on making great products and be clear and direct about what they are selling. There is nothing wrong with selling proprietary software or charging license fees — just be clear about it. Don’t call a license fee something else to give the appearance that the software is free. Éric also gives a lot of credit to commercial software vendors that contribute to open source (like Atlassian, Day, and IBM) without making a big deal about it.

Apache Software License, Hippo, and BlueNog

Thursday, July 9th, 2009

When I first got interested in open source software there was a lot of talk about the restrictions and liberties of various licenses and the risk that free-riders posed to the system. I have to admit that I never found these topics very interesting and usually referred the conversation to my colleague Stephen Walli (who is way more qualified in this area than I am — lawyers even listen to him!). For the most part, these (as well as the whole indemnification and SCO hysteria) have turned into non-issues, particularly for my clients who are users of the software and will probably never read a license anyway. Things tend to work themselves out.

But every once in a while, something interesting in the topic of licenses does pop up. You may remember I wrote a post describing how Bluenog took Hippo CMS, slapped their logo on it and sold it as commercial software. Well, they are still at it and they have even gone further as to remove any acknowledgement that they are repackaging someone else’s software. The Apache Software License, which Hippo CMS uses, is very permissive and only requires that redistributions of the software contain a notice file giving credit to the original developers. Bluenog isn’t even doing this. And, as you would probably expect they are not contributing back to Hippo either.

Bluenog is clearly in violation of Hippo’s licensing terms so it may not matter what license Hippo is distributed under, but it did get me thinking about licenses again. The Apache Software License has been used very successfully for infrastructural components like the famous Apache HTTP Server and all those great Java frameworks and components. The key benefit there is achieving broad adoption. The terms are so generous that there is virtually no downside to including an Apache licensed component in your software. Adoption is a good thing for frameworks and components because lots of users help find bugs and help the project move forward. Even if a very small percentage of developers contribute back, the scale of the user base translates into a lot of support. This low barrier to adoption is particularly good for reference implementations of standards. Tomcat, Slide, and JackRabbit were all critical to the success of the standards they promoted.

As good as the ASL is for components and frameworks, I question its efficacy for business applications. Business applications, like Hippo, compete in a different market than infrastructure. They are going after a smaller (higher touch) install base and they are more actively competing against other products. Business applications need to innovate and differentiate from their competitors while infrastructure wants to be stable and standard. The potential for free-riders to undermine your investment to be unique is too great. This is why most other CMS on the market are licensed under the GPL or a similar license.

From a consumer perspective, it feels like Bluenog customers are getting ripped off. They are buying a software application that should be free. Customers are essentially paying Bluenog to ask questions on the Hippo mailing list that Hippo and the community are answering for free. It feels like Bluenog’s refusal to acknowledge Hippo is an attempt to protect this arbitrage. Had customers worked directly with Hippo, they would not only save money, they would also know that Hippo has an entirely new product: Hippo CMS 7 that is a ground up rewrite from the 6.x series that Bluenog forked. I do think that this issue will eventually be worked out. Bluenog will probably not be able to continue practicing business in this manner: even if lawyers don’t get involved. But, as you can probably tell, this drama does rankle my developer and open source sensibilities.

Is this CMS worth the money?

Monday, June 29th, 2009

During any CMS selection, it is fairly common to look at software products that span a wide range of prices — everywhere from free to several hundred of thousand dollars in up front licensing. Buyers invariably get confused as they consider vastly different pricing models and try to put those numbers in context of the whole project costs. They struggle to force different products into an “apples to apples” comparison. And, all the while, they are told by the vendors that each solution is the really the cheapest in the long run (bring on the tired free puppy analogies).

Content management software feels worse in this regard than other types of software selections. For one, there is no clear market leader in content management software. This means there is no single company to create a “gold standard” for feature/function/price. Secondly, it is not the case that the large vendors are more stable or offer more features than the mid-market and open source providers. In fact, it has been quite the opposite. The household brand names like Interwoven, Vignette, RedDot have all been in pre-acquisition balance-sheet-beautification mode over the past few years. In other words, they have been minimizing engineering investment and milking their customer base for revenue. Even during the Web 2.0 boom, what little engineering money was spent didn’t make its way to web content management. With all of the high profile corporate acquisitions of Interwoven, Vignette, and RedDot, high end buyers didn’t get the stability they were looking for either. So, the old adage “you get what you pay for” didn’t hold up for the high end web content management marketplace. The middle tier of commercial software vendors have been delivering better products with less risk than the upper tier.

“You get what you pay for” didn’t really hold up on the free end of the spectrum either. There are many examples of successful implementations built on top of open source software. These solutions were not entirely free. They cost money to implement and customize and many customers purchase support and maintenance but, then again, all content management software (commercial or open source) requires customization and integration work and maintenance can be 20% of licensing cost. My experience is that open source solutions are generally no harder or time consuming to implement than commercial software solutions (and I have implemented plenty of both). The way to reduce the cost of the entire solution is to minimize your customization/integration work by choosing a platform (commercial or open source) that best matches your requirements. It just may be that the closest match is open source.

When talking my clients through a selection, I am often put on the spot with a question like “what additional features do you get when you go with the more expensive products?” A similar question is “what will we get if we spend more?” These are hard questions to answer because there is no single feature that only appears in higher end products. Usually the best I can do counter with an analogous question “is a Porsche Cayman worth the $23,000 extra in price over a Subaru Impreza WRX?[1]” Both have 265HP engines. Both have many of the same features (radio, air conditioning, speedometer, tachometer, airbags…) but they are very different cars. Obviously some people think the Porsche is worth the extra money. But I can’t tell you whether it will be worth it to you because it is a personal feel thing. You get in the car and it feels right. You might even find that you like the less expensive car better because of the arrangement of the controls is more intuitive or the shape of the seats fits your back better. Of course, if you don’t have $55,000 for a car, you can save yourself time by not looking at Porsches.

Open source software can be the same way. You might find a particular product whose feature list is very similar to a commercial application you are considering; it has versioning, workflow, a powerful content modeling framework, in-context editing, image manipulation, etc. But these features may have been implemented in a slightly different way — not better or worse, just different; and not because of the licensing model but because two different engineering teams implemented the features. I can’t predict which alternative will feel right to the prospective user base. They need to experience the products to make the comparison.

The goal of my selection process is to present products that match my client’s stated requirements. To use that car analogy a little more, the cars with the right size engine, the right number of seats, and below a certain price. I also look at industry filters like what is happening with the vendor (I have not recommended Vignette, Interwoven, or RedDot over the last three years because it was pretty obvious the direction they were going). Then I provide some exercises to help the client “test drive” each short listed solution and experience its characteristics and feel. We still do have discussions like “is this CMS worth the extra $100,000?” but only after the client gets a true feel for the differences in the products (and the vendors behind them) and maps these differences to the needs of the organization.

Notes

  1. I dislike car analogies but nobody seems to know very much about bicycles.

Django Contrib

Monday, February 23rd, 2009

Jacob Kaplan-Moss wrote very good post on the purpose of django.contrib. For those unfamiliar with the Django project, django.contrib is a tightly managed, highly used collection of modules (packages in Python). Contrib is not quite Django core, but much more part of Django than the free-for-all of shared re-usable applications.

The reason why I find this interesting is that many open source projects struggle with the balance between the benefits and risks of maintaining a low bar to contribution. The generally adopted policy is to keep core development within a small trusted group of “committers” (who can commit their own and patches by others that they have reviewed) and then open up module development to rest of the world. What usually happens is that modules can be highly redundant and inconsistent on quality. Add-on modules are typically the greatest cause for system instability and insecurity and the most difficult to upgrade. But they are still great because they are code that you don’t need to write. Drupal, with its explosive community growth, struggles with this balance. Drupal developers often find that it is easier to write a module than to find one that is well written and does what you need it to do. Yes, there are Drupal modules that rise to the top and eventually get included into the core (Views, CCK, etc.), but they are rare. Sometimes there are random reversals – remember when CCK overtook flexinode?. The rest churn in the rough and tumble Contributed Modules library. Other projects have these issue, Drupal’s growth and scale just make it more visible. Typo3 had a rating system (“no cigar” through “Cohiba”) but the initiative fizzled.

Back to Jacob and django.contrib… Contrib is a very important resource for the Django community. The packages there are widely used and considered (by many) as good as core Django code. If a developer finds a module he needs in contrib, he will use it rather than any other comparable module he finds elsewhere. Contrib modules are actively maintained and are tested against new versions of the core. They are “sanctioned” not just for what they do but how they are built. In his post, Jacob recognizes the impact of incorporating a package into contrib and tries to clarify what incorporation means. Jacob proposes three tests to determine whether a package gets into contrib: the functionality should be optional (that is Django won’t break if you delete contrib from your system), it solves a common problem, and it exemplifies generally accepted best practices.

Jacob also writes that contrib packages should conform to the same standards and guidelines for the general module population. For example, they shouldn’t access Django’s “brittle internals” (that is, functionality not wrapped in an API that may change without warning). The rest of the post goes through examples of packages that should or not be in contrib according to his tests.

I think more projects should have a system like django.contrib or at least have an open discussion around what makes a preferred module. As Typo3 found, it is hard to instate one after the catalog of modules (and community of developers) has grown beyond a certain size. Putting the best modules into core carries the risk of bloating the core application with functionality that not everyone needs. The various Linux distributions that have package managers are able to put preferred modules in their package library (accessible through tools like port and yum). The last resort, which is where most big projects are, is to have a good network of developers and do your research from word of mouth.

The Art of Community

Monday, February 2nd, 2009

Not that long ago, I started reading The Art of Community. Jono Bacon is posting to this blog as he writes an O’Reilly book by the same name. You can read drafts of the first chapters here and here. I expect demand for this book to be high because communities are valuable but very difficult to create. Companies often envy the passion and personal investment that some open source communities have been able to inspire and they get frustrated when their community building attempts fail to thrive. Jono has been involved with Linux and KDE and currently serves as the Ubuntu Community Manager for Canonical so he knows a thing or two about open source communities.

I have written on the topic of evaluating the health of a community and have been approached by more than one software company looking for that special sauce to help create a self-sustaining customer community. One thing is for certain, communities are not built on tools – it takes more than a forum or a wiki to make a community. Tools like these can help an existing community communicate better but they can’t establish a community where there isn’t one. A successful community requires a purpose worthy of passion (for a great discussion on this, see “Would you Join a Toothpaste Community?”), leadership to help people productively focus their passion, and methods for people to get value out of their participation.

So far, the best book that I have read about the community aspects of open source software has been The Success of Open Source. The Art of Community will have a much greater focus on how to create a community. The table of contents looks like a manual for a community builder. One thing that I would like to see, but haven’t yet, is a set of strategies for creating a passion-worthy purpose out of a seemingly mundane topic (like toothpaste).

Part of the writing process involves building a community of readers and harnessing their input. The project is still too young to see if there is any traction. I am looking forward to seeing how both the book and the community around it come together and if purpose, leadership, and value emerge.

Tale of two developers

Monday, January 26th, 2009

Angie Byron, has wonderful post on approaches to contributing to an open source project. She makes her point in parallel stories of an outgoing developer who puts a lot of intermediate versions of her code for public review and a perfectionist who holds back code that is not finished. Through the narratives, Angie shows how submitting lots of code helps leverage the collective knowledge of the community to learn better programming skills. Submitting code and interacting with the community also helps a developer build relationships with other developers who will be more likely to help her out.

With all of the focus on cost savings and intellectual property, the educational aspect of open source software is frequently overlooked – at least by business decision makers who have no idea how poorly written their in-house developed code is. Open source software has advantages over in-house software that extend beyond simply having more programmers eyes on the code; the ability to interact with similarly inspired developers across corporate boundaries can be a huge benefit that translates into professional development and job satisfaction. Of course, this value does not come for free. Like any other activity that builds skills, working on open source takes time. A manager should consider the educational aspects of open source software when developing a professional development program for his/her technology team. If you think of the time and expense of going to a traditional conference where a developer will, at best sit passively through conference sessions, working collaboratively on a real project either remotely or with developers at a sprint. This does not have to be limited to open source software but the open source licensing model certainly helps. There are some commercial products with active developer communities modeled after open source communities that share code and interact. If you have a large in-house development team, consider practices like pair programming, commit mailing lists, and code reviews that help turn programming into more of an open, collaborative effort.

A tale of two developers belongs on my “all time” open source reading list. Thanks Angie!