Open-source Product Development

Explore top LinkedIn content from expert professionals.

Summary

Open-source product development means creating products in a transparent way, with public access to code, plans, and feedback channels so anyone can contribute ideas or improvements. This approach encourages collaboration, builds trust, and allows products to grow through community-driven innovation.

  • Share transparently: Publish your product roadmap, codebase, and upcoming features so everyone can see and participate in the direction of your product.
  • Invite community input: Set up public feedback channels and make it easy for people to suggest ideas, vote, and join discussions about new features or fixes.
  • Respond quickly: Monitor community activity and provide prompt feedback to contributors, which helps build trust and keeps people engaged with your project.
Summarized by AI based on LinkedIn member posts
  • View profile for Zohar Einy

    CEO at Port.io

    10,503 followers

    Our product roadmap is open for anyone to see. Sounds crazy, right?  Well, here's the story behind it: When Port was six months old, we had one product manager (shoutout Dudi Elhadad), no sales team, and a product that was bare bones compared to what we have today. We were a new SaaS company asking engineers to trust us. And we had to earn it. So we took cues from open source. We opened up. We open sourced our integrations (Ocean) We put a live demo on the site with no gate Built a Slack community (12,500+ members) and published our product roadmap on Canny Our public roadmap shows what we're currently building, what's next, and what we're planning for the future. Anyone can see it. Anyone can tell us we're wrong. (Not just customers) Since then it's gathered: - 1,250+ feature ideas - 10,450 votes - 1,726 comments from 43,200 users Every month we get about 80 new feature requests, 460 votes, and 86 comments. Some of our best features actually came straight from there: - "View As" had 155 votes. We shipped it and now builders can see Port exactly how their end users see it. - Custom icons had 123 votes - Dark mode had 73 These aren't necessarily features we would have prioritized on our own. But when that many people care about something, it's meaningful. Some customers even write requests that read like PRDs with a target persona, problem statement, and proposed solution. The public format pushes people to think harder about what they actually need. That helps us build more precisely. Publishing your plans also creates healthy pressure. When something goes on the roadmap, the timer starts. Competitors can see it too. We don't mind. If they ship something similar, it moves the whole category forward. I wrote some more about how it helps us and our customers on our blog. Link in comments

  • View profile for Andrios Robert

    9k followers. Led Cloud & Security at F500s and unicorns. Founder @ Hoop.dev.

    9,533 followers

    Just took a huge leap of faith and open-sourced our codebase! 🚀 It's been a wild ride, and I want to share why we made this decision. Three years ago, we were struggling to gain traction in the crowded access gateway space. Our tool was the #1 product by far, but adoption was slow. We knew we had to do something drastic. That's when it hit us – what if we embraced radical transparency? We spent months debating, planning, and frankly, sweating over the implications. But last week, we finally pulled the last trigger. It started with a free SaaS plan, then free self-hosted, free open-binary, and now, we're also open-source! Here's why we believe this is a game-changer: • Community-driven innovation: By opening our codebase, we're tapping into the collective genius of developers worldwide. The improvements and new features that have already poured in are mind-blowing! 🤯 • Trust and credibility: In an era of data breaches and privacy concerns, showing our cards builds instant trust. Customers can see exactly what they're getting. • Faster bug fixes: More eyes on the code mean quicker identification and resolution of issues. Our response time has already improved by 40%! • Talent attraction: Top developers want to work on exciting, open projects. • Ecosystem growth: Third-party integrations and plugins are flourishing, expanding our tool's capabilities beyond what we ever imagined. Of course, it hasn't all been smooth sailing. We've had to adapt our business model, breakdown features and paywall our unique value props. But the energy and momentum we've gained far outweigh the challenges. And the surprising outcome: the features in the open-source package beat enterprise plans of all competitors. To my fellow tech leaders: consider the power of openness. It's scary, yes. But the potential for growth and innovation is enormous. Have you experimented with open-sourcing in your company? What were your experiences? Let's discuss in the comments!

  • We decided to build an open-source project and here are a few tips that helped us grow and get huge companies like Amazon, Microsoft, IBM and Google to use and promote our product. 1. Organic reach: we published the project everywhere we could, and repeated that. Hacker News seemed to be the best place to get that first momentum. Yes, the website looks like it was taken from the 90s, but you'd be surprised at how many industry leaders are reading through posts there on a daily basis. Also worked well for us are dedicated Reddit communities, and to some extend Twitter/X. 2. Friendly Experience: we made our OSS friendly for first-time contributors from day 1. We opened around 10 issues in the repository with various degrees of complexity, tagged some with "good first issue" so that GitHub search engine can index our repo and opened a community slack workspace so people can ask questions or request guidance easily. 3. Quick Response: we monitored our open-source activity closely. We set up Zappier integrations so we get notified whenever someone opened an issue or a PR on the repo - so we can respond quickly. The first few contributors are looking for a quick feedback and may quickly abandon your project if they don't see maintainer activity. Community: we actively engaged with the community. We arranged webinars, answered questions, and were quick to fix bugs that were opened. This helped gain the trust that we need to make this succeed. Building and maintaining an open-source requires constant dedication of time and effort. But once you do it right, it’s a great way to get exposure to what you’re building. What is your story? How do you grow your open-source projects?

Explore categories