22
34 Comments

The fear of open source

As a developer myself, I am struggling to find a balance between open and close development.

My MVP is very rough around the edges, and the first audience will be techies comfortable with low-code tools. Why? Because making something usable for non techies takes a ton of extra polishing. However I find quite alarming being surrounded of geeks like me.

One one hand they might say "Oh! I don't trust closed source tools" and on the other there are the code nazi bastards: "I can't use your software. I saw your repository, the code is a mess and there are not enough tests!"

I know there are plenty of apps and websites that do not publish their code. However "the product birth" will start with a npm package that is mostly a pre-built bundle. That seems fishy to me on the node-js world

I want to avoid the pain of choosing a license so early which I might regret later. It seems easier to start fully closed and open up slowly, than the other way around.

What I want to show from day zero is that the product is easy to customize, extend and integrate. For that I see no value at all on "open core", but a lot on open interfaces / libraries

Have you faced a similar dilemma?

  1. 6

    I’ve been building and selling open source products for the past 15 years and not once has someone commented on the quality of my code, and believe me, it’s not all roses and rainbows. 🌈😅

    I’ve opted for an open source MIT licensed product FilePond (file upload library) with a closed source “extension” called Pintura (for image editing), and I’ve found this works quite well.

    FilePond was closed source initially (GPL with commercial license) and I open sourced it after a few months. It’s been a great way to upsell to Pintura.

    1. 1

      Oh, these products look very nice.

      How is running an open source project?

      I'm working on an Angular/Firebase web application and am considering releasing the project shell to open source. This would be a template to go from zero to an app with a landing page, complete auth pathways, user settings, and stripe integration. I worried it would be like another job?

      1. 1

        Depends on how much energy you get from working on it? If you love the product then it probably won’t feel like a job? Also, you’re in charge, it’s your product, you decide what issues and PRs matter.

        I spend a lot more time on Pintura then I do on FilePond, because the former puts food on the table. But that’s not a 100% fair to FilePond because it partly does so because FilePond sends traffic.

        Hoping to change that balance with version 5 of FilePond.

  2. 4

    "I can't use your software. I saw your repository, the code is a mess and there are not enough tests!"

    I think it's a tiny section of users who will respond that way. 99% of your potential users will never actually look at the source code, they'll just feel happy to see label "open source" (just like they are happy to see the word "organic" on their food).

    Some of your users will be techies who are too busy to really look at your code, but they're happy that they could look at it, in case they stumble on a blocking bug when using it.

    Some of your users are non-techies that will never look at source code, but they're still happy to see "open source", because it's like insurance. If you decide to quit the project then hopefully someone else will jump in and create a community-lead fork, and they can use that.

    1. 2

      I used to make fun of people who claim to have a great idea, but can't talk about it because without a patent, people will steal it. I wonder how far I am making the same mistake with code

      1. 1

        Ideas are free, in the ether, and not unique to anyone; code... the same.

        When I get a great idea, I talk about it to everyone. This way, maybe somebody will build it, and then I can use it :)

      2. 1

        I think software is knowledge and must be shared with humanity. My focus is on trying to share as much as possible with as many people as possible, which is very challenging. Great ideas and great software need a lot of work to be understood and put to use by lots of people.

        For me the financial sustainability comes second, not first. And because the world of software overflows with money (compared to agriculture for instance...) this never was a difficult problem to solve. I did not make millions, but I always made a decent living.

  3. 3

    For more than 8 years I thought whether I should open-source UXWizz or not, and so far the answer has been no. The problem with open-source, is that if it doesn't get popular, there's no advantage to it, if it gets popular there will be a lot of noise and extra work that has to be done just to satisfy the community, drastically reducing the available time for actually improving the product.

    1. 1

      The problem with proprietary software is that it will become obsolete when a Free Software competitor becomes mainstream. That may very well be what happens to UXWizz if Plausible keeps gaining popularity. This is what happened on a larger scale with Linux versus dozens of proprietary competitors that since disappeared in the past 20 years.

      If the goal is to make money with proprietary software until it is obsoleted by a Free Software competitor, it certainly is possible: that's what the vast majority of people do. And that's how tech giants are the richest companies on the planet.

      My goal is to improve society and making money comes second. Reason why I'm more interested in trying to build something with a long term promise... and that requires Free Software.

      1. 2

        And as Linux vs proprietary software: "Windows is the most used at 75%, followed by Apple's macOS at 15%, and Linux-based operating systems, at 5% ". I'm not saying any of them is "better", just that free is not always the answer and definitely not sustainable for the maintainers (unless their reason for building the software is other than making a living out of it).

        1. 1

          I was referring to Linux which is the kernel found on servers and android based mobiles, not on desktops, sorry about being vague. Back in 2000 there were a dozen of alternative proprietary kernels running on various hardware. They have disappeared.

      2. 1

        The problem is that the free software cannot sustainably offer the same quality. Matomo is a free alternative example, but they do lock a good amount of their features behind a (very expensive) paywall, so in the end you end up paying a lot for that "free" software to get the same features.

        Also, once a company focuses on their "premium" version, their free one is going to be getting less and less relevant, as their business goal is to make the premium one sell (attract clients from the free one).

        The tech giants don't provide free services (Google has ads in its search, Amazon sells stuff, Facebook sells ads and data, Apple sells products, etc.). Often they build internal tools that they need and make those free, but their goal with them is NOT related to their core business.

        1. 1

          The problem is that the free software cannot sustainably offer the same quality.

          There is no rationale supporting this conclusion.

          It is true that the sustainability of software is a very difficult topic in general. But it is not unique to Free Software, this is a problem for every piece of software regardless of the license under which it is distributed.

          At a global scale you will find (I don't have a reference handy but that should not be difficult to find) the income of selling proprietary software licenses is a fraction of the income selling services (human time) based on software.

          Since most of the income derived from software only marginally depends on selling proprietary software licenses, there is no reason why Free Software would be less sustainable.

  4. 3

    If you are primarily interested in building a business, here is how I thought about this when building my current startup.

    Ultimately, businesses are about making money and open source does not directly make money. Therefore, the role of open source in your business must ultimately drive paying customers. That can happen via the marketing benefit of having a popular open source project, having users of the open source who need add on products/services, consulting services, or other routes to monetization that I haven't thought of. All of this depends, however, on having lots of users of your open source software, and that is where the challenge comes in.

    The big challenge with open source is that you have to make it popular. To make it popular, you have to produce something that is very useful on its own, otherwise people will not use it. Often times, that means the vast majority of your users will have no need or want of your paid offering. In fact, the more popular the open source, I think the bigger a problem this is. The trick is building enough open source that it is popular and useful, but not so much that you cannot monetize things. Docker is a case in point of how not to do this. Hashicorp, on the other hand seems to be doing well.

    Often times, the effort to market and popularize the open source is just not worth the trouble, you should just go closed source. It seems that the key point in your post is that you find it hard to make something useful for non-techies. But those are the people that will pay because you've solved a hard problem for them. It may be worth leaning in to that audience and just doing the work to build an MVP for them. It is hard to say what the right answer is without the benefit of hindsight.

    1. 3

      My struggle is exactly that line between techies an non-techies. I am the former, and I know very well how hard it is to get money out of us. The later is my hope, and the ones I think need me the most, but polishing a MVP for them is a huge uphill struggle. I am so tempted in targeting the techies first with free stuff, just to gather some feedback but mostly start shipping much earlier. Meanwhile I know that is playing with fire, because the profile/mindset of free users tends to be wildly different from paying ones.

      1. 1

        My experience with this is that if you are building for non-techies, feedback from techies is not very helpful. I'd think about the fastest way you can get feedback about your product from your target non-tech customer. If you can do this before you build it, even better. You will likely burn a ton of time trying to attract the techie audience, and not get much in return for it long term. Of course, the devil is in the details.

        In the case of our startup, Adaptable.io, developers who understand and have built their own AWS or K8s setups did not have helpful feedback. Users that had no idea how to deploy their own software gave us way better feedback and more relevant feedback. Of course, the best feedback came from folks who knew how to build their on Continuous Deployment pipeline and decided they didn't want to do that anymore.

    2. 2

      This is a well articulated reasoning. But I have to disagree because it is based on an assumption that is incorrect:

      The big challenge with open source is that you have to make it popular.

      This is not true. It is a challenge to make anything popular, of course! But there is no popularity requirement for Free Software. There is no downside to publishing all the software a company does as Free Software. No obligation to build a community either. Most people think there is but it is a myth: there is just no evidence supporting it.

      There is one major upside to Free Software: it may have a long term future, being used by everyone on the planet. Try to do the same with proprietary software and you end up with monopolies such as Google or Microsoft. But that not the goal of anyone here: we're on indiehackers, aren't we?

      1. 3

        If you are writing software and releasing it for free for non-business reasons, I agree with you wholeheartedly. However, if you are trying to build a business, I don't see how releasing it as open source really helps your business if it isn't popular, and I can see numerous downsides.

        That said, I do think many businesses believe their code is the valuable part of their business when it is really other things, like sales channels, brand recognition, network effects etc.

        1. 1

          ... I can see numerous downsides.

          I understand why you would imagine these downsides exist although there is no evidence. They are theoretically possible.

          I don't see how releasing it as open source really helps your business

          Think UXWizz versus Plausible: would you bet on the proprietary one or the Free Software one, all things otherwise equal?

  5. 3

    Yeah I think you should just publish - do not get worried until your project explodes in notoriety ;)

  6. 2

    I'm a software developer and made a living publishing and using exclusively Free Software since the mid 90'. Ranging from being an employee to running a company with employees. From developing hard core tech (self healing distributed storage) to selling services on a niche market ( online poker server and web client ).

    There is one thing I learned: the odds of a competitor using your codebase to run their own business in way that will effectively hurt yours are virtually non-existent. It is theoretically possible and that's what is scary. There are a handful of spectacular examples where that indeed happened (ElasticSearch) and this is even scarier.

    But letting that fear dictate how you approach Free Software would be like not boarding a plane because some of them crashed. Look around: there are tenths of thousands of companies, big and small, that run successful businesses based on the Free Software they publish. They won't become unicorns, that's a given. But is it what you want?

    1. 1

      Somehow I understand it is old school mentality trying to keep everything closed. For once I value very much sending the message of "I might fail, shutdown or even die, but the tool could live on". However it is still a whole world of GPL vs BSD vs Dual Licensing ... it is a lot of upfront work to decide without experience. I am still thinking I should lock down the core and slowly release as open source the outer layers. Picking up a license is not just a matter of knowledge, but a matter of experience since there is a high degree of personal comfort in each choice

  7. 2

    Don't be afraid of open source. I built and sold a 7figure business on WordPress. Code was there for the taking but didnt matter.

    1. 1

      I'm interested to know more about this success story.

        1. 1

          Thanks. I don't see that https://www.learndash.com/ was published as Free Software though: where is the code?

          1. 1

            Ah, yeah repo isn't public i believe, but it's open source. tho that didnt stop ppl from posting it places and reselling it since technically that's not breaking any rules with open source.

            1. 2

              Oh I see. There is a world of difference between publishing Free Software to the general public and developing it in a publicly available location versus developing it in secret and only handing out copies secretly to customers. Those customers had the legal right to redistribute the learndash publicly because it is required by the Wordpress license.

              I think the original question of this thread was about publishing Free Software to the general public, which is something else.

  8. 1

    Does open source benefit for your business? Like sample code or how inside of libs works so clients can better use the product? Or you are just nice to publish?

    I had some security background and in that sense open source is not a great idea, particularly on sensitive information.

    I personally prefer the hybrid approach so I can have options either way

  9. 1

    What scars me of opensource is, that most projects are either abandoned or lack proper support. I have to personally rip several open source libraries and replace them with new ones several times in my projects.

    1. 1

      As someone who ran an open source project for 5 years I can tell you I have scars from sinking thousands of hours into it and getting very little in return.

      I think the problem is, people confuse "open" with "free". Unfortunately supporting an open source project takes a lot of work and the burden grows as it gets more popular. It's very asymmetric in the wrong direction.

      For the record, the open source project I started those many years ago is still alive and well. I'm just not apart of it anymore. Other people are supporting it though.

      My take on open source is that it creates trust because it's very clear what people are getting. They can verify the source themselves or at least assume someone else has verified it

      1. 1

        I think there should be some path for open source projects towards monetization. Commercial users like us should be charged when asking for bug fixes and new enhancements, this way it guarantees we get the long term support and in return the project contributors are commercially rewarded. Prioritize bugs and features based on monetary reward just like bug bounty.

        1. 1

          Totally agree. There are actually some ways to monetize open source that have worked for some people.

          The first way is the open source hosted model. A great example of this is Plausible Analytics. The idea is simple, keep the code open source and offer paid hosting so that people don't need to run and manage their own servers. This works well for web based projects, but not much else.

          The second way is the Patreon / Github Sponsors model. The best example of this I can think of is Vue by Evan You. The reason this model works (IMHO) is because the market for this kind of thing is massive, Evan has a good reputation and many companies use Vue in their tech stack, so they're happy to support him.

          I haven't seen anything else work well, but I'd love to be surprised.

  10. 1

    In my opinion, the biggest disconnect I see is with privacy. On the one hand, I understand that verifying claims made about protecting a user's privacy are easier to do when there is access to source code. On the other hand, only a handful of users will compile or know how to verify a distributed app is built from that code base. So, in reality, almost no apps are ever verified and the level of trust shouldn't be that much higher.

  11. 1

    This comment was deleted 2 years ago.

Trending on Indie Hackers
Passed $7k 💵 in a month with my boring directory of job boards 53 comments Reaching $100k MRR Organically in 12 months 35 comments How I got 1,000+ sign-ups in less than a month with social media alone 19 comments 87.7% of entrepreneurs struggle with at least one mental health issue 14 comments How to Secure #1 on Product Hunt: DO’s and DON'Ts / Experience from PitchBob – AI Pitch Deck Generator & Founders Co-Pilot 12 comments Competing with a substitute? 📌 Here are 4 ad examples you can use [from TOP to BOTTOM of funnel] 10 comments