Open Source as a Service

[stefwalter]

This is an article describing why and what it means to enable Open Source contributions to a Service.

Sharing the source code to a Service is insufficient. We effectively enable users to contribute to the a running service for it to be Open Source.

[stefwalter]

@martinpitt @thrix @TomasTomecek @major @durandom @emmanuelbernard @gsaslis Interested in reviewing? Here's an introductory blog post about the Open Source Services topic we've talked about.

I'm thinking of following it up with more content, perhaps some of the playbook ideas we've already drafted together. But one thing at a time.

[martinpitt]

Very nice article, thanks!

[martinpitt]

Connecting that to your point above -- the only way that this is feasible is if your own little shard of that SaaS with your PR operates on a cloned subset of the production data. If any random Joe Developer could submit a PR against gitlab that runs on the production data, what trust could you still place in the gitlab Saas? IMHO, it would be "none".

But again, I think having a playground with empty (or cloned data that belongs to you) is actually preferable, as it gives you the possibility of doing thorough, destructive, and risky tests.

[stefwalter]

I'll cover this in follow up articles and playbook. I believe that your statements are just as true of team contributions.
Many teams only merge code once they have gotten it into production. See the GitHub internal contribution process.

But yes, I'm happy leaving this as a controvesial topic to be discussed further.

[gsaslis]

@martinpitt i think the crucial bit that is mentioned above is that this change would only affect your data / how only you consume the service.

I think of it like this:
many SaaS offer an option to try their "beta" features or become part of their "fast" channel, with latest changes not-yet fully tested on everyone else. Other SaaS A/B test features all the time, so it's not like all the users of the service experience the same service anyway.

Switching to "contributor mode" for an Open Source Service would be very similar to those cases but the features you are beta testing are simply your own.

[stefwalter]

Thank you @martinpitt for your valuable critique and review. I hope I've addressed the points you raised.

One point in particular (about sharding/cloning data) is better covered in a follow up, and is a key example of the areas where we must apply existing known deployment techniques to solve.

[martinpitt]

Thanks, this sounds great to me now! I can't resolve my comments above, but please do so (especially if/when others chime in, to keep track of discussions).

[martinpitt]

Not for your article (perhaps), but a thought: Achieving this would also mean that you have full control of the "real" deployment, and constantly exercise and improve its (re)deployment. The importance of that can hardly be over-estimated for a project's/company's long-term resilience.

[gsaslis]

Thanks for bringing this out @stefwalter ! Love it.

I've left some minor edits that I think help readability. I also left some comments that I think help bring more emphasis on "Open Source Services" - so that this endeavor has a nice catchy name that will help us pull more people behind it.

[gsaslis]

@martinpitt i think the crucial bit that is mentioned above is that this change would only affect your data / how only you consume the service.

I think of it like this:
many SaaS offer an option to try their "beta" features or become part of their "fast" channel, with latest changes not-yet fully tested on everyone else. Other SaaS A/B test features all the time, so it's not like all the users of the service experience the same service anyway.

Switching to "contributor mode" for an Open Source Service would be very similar to those cases but the features you are beta testing are simply your own.

[radekvokal]

Hey @stefwalter , /lgtm . One thing I'd add is to figure out how to capture and open SOPs -- standard operating practices. You're talking about opening access to the components/services and making transparent changes there - that's great but I feel like it's often not about what you run but how you run it - how you operate it. That experience is often encoded in heads of SRE/operational team - debugging and troubleshooting services, actions triggered by monitoring events etc.

[durandom]

❤️ it

[TomasTomecek]

Very nice! Would be nice to add at least a single picture so it doesn't feel like a wall of text :)

[stefwalter]

Thanks for reviews. I've made all the changes, but I agree we could add a couple pictures. I'll work on those.

@durandom @martinpitt @gsaslis @TomasTomecek @radekvokal Would you be open to me linking back to this pull request at the bottom of the article as a way of thanking you for your feedback?

[thrix]

I did not find anything to comment, lgtm

[martinpitt]

@stefwalter : Sure! Linking to PRs is very much the spirit of FOSS 😉