Shane is founder of Punderthings℠ LLC consultancy, helping organizations find better ways to engage with the critical open source projects that power modern technology and business. He blogs and tweets about open source governance and trademark issues, and has spoken at major technology conferences like ApacheCon, OSCON, All Things Open, Community Leadership Summit, and Ignite.
Shane Curcuru serves as VP Brand Management for the ASF, wrote the trademark and branding policies that cover all 200+ Apache® projects, and assists projects with defining and policing their trademarks, as well as negotiating agreements with various software vendors using Apache software brands. Shane is serving a seventh term as an elected Director of the ASF, providing governance oversight, community mentoring, and fiscal review for all Apache projects.
Otherwise, Shane is: a father and husband, a BMW driver and punny guy. Oh, and we have cats! Follow @ShaneCurcuru and read about open source communities and see my FOSS Foundation directory.
Authored Comments
The brand is (for a short definition) what the world perceives as the product or organization's identity. It's how new users (and potential contributors of all sorts) find you, and it's the symbol everyone else associates with who you or your organization are.
Trademarks are the legal instantiation of a brand. Trademark laws are both fairly complex, rely on tiny details of how your web pages are presented in the real world, and - on top of that - are widely misunderstood. More to the point, you generally can't share a trademark across organizations, because the entire point of a trademark is that consumers associate a *single* entity with the product they're buying or using.
Obviously, it depends on each organization and their goals - and how the marketplace of potential competitors acts - if trademark law will actually matter in daily life for your project. Unfortunately, when trademark disputes do come up, they can be very messy, and can be hard for traditional open source projects (especially nonprofits) to fix once a problem comes up.
And your example is a perfect one: Gratipay versus Liberapay - forks in code and business models, but different brands and trademarks. While the differences are obvious and intuitive for people working on these projects, the main difference to other humans is the world is the brand.
The first question to ask anyone looking askance at a well-run open source project using a proprietary tool is: Do you use a Mac, or Windows, or a commercial Linux distro? If so, why do you use that proprietary tool?
Ideological purity is fine if that's your primary goal, but for most open source communities the goal is to 1) make software that's useful for you, and 2) try to encourage others to contribute to your project. And for any independent or small-scale FOSS project, you're probably doing this on the cheap as well. Thus, using whatever tools are most *effective* for your existing community is a good choice - proprietary or not.
Thus, many Apache projects use JIRA, since the maker has donated a free license to the ASF to run that powerful issue tracker. It's got far more functionality in an easy to administer platform (remember: the ASF runs it's own servers for this stuff) than other open source alternatives, so it's well worth using to get our project communities the functionality.
There are plenty of companies that will donate development-focused software licenses to bona fide FOSS communities, so it's worth asking around if you're in the market.
But I agree: it depends on *how* the proprietary tools affect your contributor's workflows. Anything that is 1) costly for developers, or 2) forces the project development cycle to be locked into that one vendor is definitely a danger - both to attracting new contributors today, as well as to longevity for your project when that vendor ups their prices.
Followup to this article: excellent point raised that any FOSS communities that do use proprietary tools should do the research and explain *why* it's a good idea, and how / if it affects IP rights of contributors. It's far easier for the community to collect this research and present it than hoping that every potential contributor will do it.