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 fourth reason to embrace rejection:
- Some projects do things differently. Just because your code is formatted correctly and *you* think it's a great new feature, it may not fit in the vision and roadmap that the project's maintainers expect.
That doesn't mean you don't have a great idea, it just means that the particular project isn't interested in it for the time being - and that's OK. That's the whole value of open source, that different communities can work on different efforts.
Separately, the flip side to this article is: If you are an open source maintainer, don't worry about rejecting submissions - but do it politely! Rejecting a submission with comments like "RTFM!" drives away not just that contributor, but others as well. Taking the 2 minutes to write a polite reason why you're rejecting the submission is the hallmark of a project that welcomes new contributions.
Remember how I said that trademark law is widely misunderstood? 8-)
> "But enforcing trademark law is expensive and difficult, requiring constant vigilance, and neglecting to act to protect a trademark means giving it up (yes?)."
It depends, but in general, no to all of the above - at least in the practical cases that open source projects like we're talking about here deal with.
This is a much bigger conversation than a reply thread here, but suffice to say there are a bunch of fairly simple things you can do that give you decent insurance about protecting your trademark later. Picture it like insurance: you have to pay (a tiny bit - in project organization, not money) up front, for protection later.
If you don't act at all to protect your trademarks now, *if* something comes up later, you'll be stuck. But with a little work beforehand, you have a reasonable ability later to *choose* if you want to defend the trademark or not.
Thanks for the GitHub mention, will follow over there.