I just got a new job building an MVP for a small startup. We're building an interactive web-based app to be used in K-12 education - something that is fun and engaging for students, and helpful for educators to build in lesson plans and view their students' engagement.
As a developer, I'd like it to be open-source. I don't expect that it's a project that the community would be contributing to - as our use case is somewhat specific - but, I'd like to be able to keep a public journal of my experience working on the project, and allow others to see how I am approaching problems with a production-scale app. Spectrum recently open-sourced their platform and looking through it has been illuminating.
In short: I couldn't be where I am now without learning from open source software, and I'd like to find ways to share what I have learned in the context of a "real" production app.
I think many business owners would err on the side of closed source, the most obvious reason being that they wouldn't want to provide any benefits for competitors.
🤔Has your business or the business of your client benefitted from open-source?
🤔Have you had this kind of conversation with your client or employer?
🤔If you've thought about this for your business, what went into your decision making, and which route did you take?
Top comments (4)
When I freelanced I would explain to clients that we (“we” not “I”) would be using open source and that it let us do much more, faster, and for less. And because of that if we did things that weren’t critical to the business or would harm them and if I felt it would be useful to others then we’d open source it.
Only one customer ever had an issue with this, but they also had an issue using open source. We didn’t work together.
Most of my github repos and gems are a result of this arrangement.
Is the software really how we make our money or is it a support mechanism?
Is our code so re-usable that our competitors would actually steal it?
Do we get bug reports that could conceivably be investigated by the person who reported it?
Are any of our customers/fans software devs?
Are there future employees who might be enticed into working for us because they already have some familiarity with the code?
Are there future employees who might think it's righteous that we create open source code and want to work for us?
Is there an opportunity to catch this wave before it passes us by?
The first discussion is about USING open source. Philip Hallstrom puts the justification very well: 'it let us do much more, faster, and for less.' For me it's important the customer understands that "using" open source entails contributing back patches when we resolve issues or missing functionality for ourself. This is usually not a problem.
The second discussion is about releasing your completely independent work as open source. My favorite tack is explaining that if we're clever about how we build this, we should minimize and focus the code that's actually unique to YourBusinessTM. THAT'S the part that's mission critical, THAT'S the part they want to spend money supporting. The rest of it should be broken into pieces that other people will be interested to use and support as well. If they're lucky (or willing to spend a fraction of the cost of support on building community), they'll find "the rest" of their application gets supported "for free" by an organic community of self-interested users. After convo number 1, that model is something they can understand.
I often explain "code as a cost center" - the smaller and more tightly focused the code you have to maintain, the cheaper and simpler it is to maintain. Really, YourBusinessTM should only care about maintaining the part that is their unique business logic. For the rest, it's even worth spending money to try and build some community to support it... because that's way cheaper than developer salaries these days.
Source: My job is convincing huge companies to collaborate with us on open source solutions to their tech problems, and then doing the development with them.
Ironically, I've pretty much defaulted to "open publish": 1) I figure "who's going to steal my crap code"; and, 2) leaving it on public repositories means that I can find it again later if I ever move on/lose my credentials/etc.
The funny thing is that the pressure to not be open that I've run into is based on people not wanting to end up being the latest "thus and such company leaked confidential information" boat. A lot of developers — particularly those that come from closed backgrounds — have really sloppy practices with their code. I mean, even aside from the litany of "public S3 bucket" stories, most of us have read the various cautionary tales around: credentials pushed to GitHub; API tokens left in anonymously-browseable, public facing Jenkins servers; etc. At this point, some of those who are unsure of their own habits are terrified of open publishing.
I imagine it's that (near) terror that plays into why people choose to run their own Git servers when their workloads really wouldn't otherwise justify the efforts to do so. ...And why one of the companies my company has partnered with on a project has been "hinting" at the need to move all the code I developed for the project to their private GitLab instance: in looking at their initial PRs to forks of my code, they committed some practice-errors that could have proven embarrassing. Fortunately, they'd duped my public repo to their private git server and it was in looking at their private PR that I was able to see the various "no: for your sake, that's so not going to be merged back into my public repo."