GitHub Seeks Feedback on 'Open Source Sustainability' (github.blog)

Devon Zuegel, "a developer with a passion for governance and economics," recently became GitHub's open source product manager to "support maintainers in cultivating vital, productive communities" -- specifically open source software (OSS).

Thursday they put out a call for feedback from open source developers about their contribution hours, their projects, and especially their issues: As the OSS community has grown in scale and importance, the way we think about working together has to evolve, too. What works in a village or a town needs to evolve to serve a metropolis. Open source has grown from a small, academic sharing network to a giant, global web of dependencies. It now forms the backbone of the internet and technology in general. Just like any growing city, we have to coordinate the knowledge, infrastructure, and tools for the good of the whole community. OSS is an essential and special part of software development.

OSS has also been the heart of GitHub since the beginning. However, there is so much more we could do to support the people behind it. I have many ideas, but first I want to hear from you.
The essay argues OSS maintainers and contributors "don't have all the tools, support, and environment they need to succeed," including analytics, communication resources, recognition and "proportionate incentive to contribute time and money to creating and maintaining projects." (As well as deficiencies in both governance and mentorship.) And at the bottom of the blog post, there's a contact form.

"I want you to be part of the conversation and our roadmap. These challenges are nuanced, and they are unique to each project and community, so it's crucial that we have an open dialogue as we focus on helping you address them."

Comments

Three Step Process

[drinkypoo]

1. Embrace
2. Extend
3. Extinguish

Wait, what was the question again?

I have a problem with the paid support model

[presidenteloco]

of FOSS, because it preferentially promotes creation of overly complex software artifacts / applications that require lots of support.
It also would tend to encourage crap / no / minimal documentation.

So some alternative to that model would be helpful.

Re: I have a problem with the paid support model

[Zehsi]

like libreoffice, blender or gimp.

Young Whipper Snapper

[Anonymous Coward]

A man walks into the mayor's office and says, "What works in a village or a town needs to evolve to serve a metropolis. City management has grown from a small, academic sharing network to a giant, global web of dependencies. It now forms the backbone of the governance and economics in general. Just like any growing city, we have to coordinate the knowledge, infrastructure, and tools for the good of the whole community. So, hit the bricks as I remake NYC in my own image."

I think it funny, btw, that he's quick to spin "small, academic sharing network" and ignore that the "giant, global web" was also heavily supported by industry. What has made it work is heavily either (1) wide adoption of open standards and/or software or (2) monopoly position to create a de facto standard and/or software. Meanwhile, many foundations and organizations have arisen to address the many issues he has stated, with many such (Apache Foundation comes to mind) serving as an umbrella for critical software development when an author of an important project either asks for help or simply abandons it because they're no longer interested.

It's not that his concerns aren't warranted. It's that as best as reasonably possible they're currently being addressed as needed. He doesn't really bring new ideas to the table. His call for a conversation are at best naive because it implies that he actually can meaningfully provide support and guidance. His position, though, puts him in the same position as NYC mayor: deeply political with his or his handlers own vested interests making it impossible to ever really trust him.

There's simply little, to no point relying upon him until many years have passed and he's earned the trust of people just like many other foundations have done. That almost certainly means spinning Github off has a foundation separate from Microsoft with financial backing from multiple, potentially conflicted companies. That's the model that's so far shown to work. Everything else is too political and manipulative for most to get in bed with.

And if it all comes down to advice? Post it on all on a Github repository and let people clone and modify it to their hearts content. Instead of seeking our advice, give us yours so we know where you at least say you stand and leave us to choose how we shall carry out that advice.

Translation

[Anonymous Coward]

"Hi, we're Microsoft.

We bought you, and now we need you to help us figure out how to make a profit off of you.

Because, we're like, a community or something."

"...we have to coordinate..."

[QuietLagoon]

Hmmm... I wonder who the "we" is? Does Microsoft plan to bring their amazing Windows 10 quality processes to Open Source?

What's missing is money

[sichbo]

We have collaboration tools up the wazoo, what's missing is a fair and obvious way to get paid for open source work. I propose a simple OS license to help actually put food on the table for open source developers. Let's call it the "Pay Me License" (PML for short.) It goes quite simply:
/*
  * PAY ME LICENSE (PML)
  *
  * Product Name: [Project bundle goes here]
  * Copyright (c): [list of owners]
  *
  * Public Key: [owner's base 64 RSA pub key]
  * Purchase Link: mailto|https://whatever?subject=[ProjectName license me]
  * Receipt File: [ProjectName].pml
  *
  * If a the above *.pml receipt file is not in the root of your source
  * tree, then this code is not licensed and you are not allowed to use
  * it. A license can be obtained from the purchase link above.
  */

That's it. Put it on every source file like any other OSS license. The contents of a *.pml obtained from the source code owner goes something like:
/*
  * Example *.pml receipt:
  *
  * From: [Owner(s)] # Must match header
  * To: [Your Company you@address.com]
  * Product Name: [must match header]
  * Receipt: [any text, transaction receipt number]
  * Public Key: [base64] # Must match header
  * RSA Signature: [base64] # RSA_SIG_OF_UTF8(LOWER_AND_REMOVE_WHITESPACE('From' + 'To' + 'Product Name' + 'Receipt'))
*/

Any project missing the .pml in its source code tree root, or any .pml file whos signature can't be trivially validated against the public key in the source header is not licensed.

Obviously there's no enforcement, but at the end of the day, even closed source commercial software with complex secret license key validation systems still ultimately depend on people behaving in a civilised manner and not circumventing them. There's also nothing stopping an author from providing license keys to certain worthy causes free of charge.

OSS Governance is Often Counter-Productive

[Slicker]

Open Source systems, such as the Desktop systems Gnome and KDE have consistently illustrated that governance beyond minimum essential for interoperability has never worked as well. With no road map, people met in common standards by natural consensus. In KDE, all decisions required 100% consensus which of course, was followed. With Gnome, leadership tried to establish standards and road maps that were seldom followed.

Also take for example Gentoo before and after it's founder. When he left to work at Microsoft, he established a hierarchical leadership structure that utterly collapsed the project. Gentoo had been a system that worked with minimal requirements of the one trying to install or maintain it. Then, it required increasingly more work month after month until more and more was breaking and many people left.

Non-governance -- software development by consensus has always worked far better than governed processes, in my experience, even in commercial software. The flat organizational structure did exactly the same thing -- caused peers to come together with common solutions by consensus. Leadership is seldom met with full support, be it leadership from individuals or from committees.

I think people like to cooperate but they do not like being told what someone else thinks is how they should do things.

feedback

[Tom]

I have many ideas, but first I want to hear from you.

Step One: Don't sell out to Microsoft.

There is no step two since you failed step one. Free Software is based on trust. Yes, there's GPL and all, but there is a lot of trust necessary to get a Free Software project running and working. Since the team is not held together by organisational structure, salaries or chain of command, trust is the glue. It's one of the reasons people fork or walk away: When they don't trust each other anymore, for personal reasons or because they believe the others are taking the project in the wrong direction.

Nobody, literally nobody who is not a complete imbecile, trusts Microsoft. With the history that company has, you would have to be brain-dead and insane to do.

Inertia will keep Github around for a long time. Moving is too much effort for many especially small projects, and it is a name with a lot of hyperlinks going in. But I'm not the only one who already moved all the project he cares about away from github and won't be starting new ones there.

You can play bait&switch with consumers. Not so much with developers.

So, for you personally there is actually a step two: Find a new job elsewhere.