Opensource.com

Successful open source products must be able to charge a cost that is sufficient to pay for the defrayed upstream open source contributions (development costs) and the downstream productization costs (vendor costs). Stated another way, products can only charge a sufficient price if they create value that can only be captured by customers paying for them. That might sound harsh, but it's a reality for all products. There's a saying in product management: Pray to pay doesn't work. With that said, don't be too worried. There are ethical ways to capture value.

Read More »

When I go back home and talk to people in the tech industry, or any other industry for that matter, about what I do and the topics I'm involved in daily, I'm usually met with bemusement at the idea of an Open Source Programs Office (OSPO). The concept of a company contributing to an open source project without obvious immediate financial benefit can be culturally strange to understand or explain. As someone born and raised in a country that has been trying to develop for quite some time, I understand and relate to that. There was a point in time when my only understanding of open source was that it was software that I could use without paying and without needing to wait for a specific issue or additional feature to be released. I could just do whatever I needed myself, locally. Open source faces many struggles in developing countries that make how it's perceived and its associations inaccurate and out of touch. I will discuss these struggles in this article.

Product marketing for COSS is materially different from product marketing for proprietary software and from general marketing practices like ads, lead generation, sponsorships, booths at conferences and trade shows, etc. Because the source code is open for all to see and the project's evolutionary history is completely transparent, you need to articulate—from a technical level to a technical audience—how and why your project works. Using the word "marketing" in this context is, in fact, misleading. It's really about product education. Your role is more like a coach, mentor, or teaching assistant in a computer science class or a code bootcamp than a "marketing person."

Read More »

The very effort of creating open source software is a massive knowledge-sharing experience, covering all the domains of software development with many methods and practices. Although there is rarely only one way to achieve a goal, open source communities have, over time, honed their knowledge into best practices as a natural byproduct of the open collaboration and transparency passed on within their respective communities. But what about best practices that span communities, which are useful beyond the unique needs of a single project and broadly applicable to any and all open source software efforts? I'll look at six different knowledge-sharing communities that take six approaches to gathering, maintaining, and distributing their best practices.

Read More »