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?

Microsoft needs your feedback/help

[wolfheart111]

Lets all just jump in there. Suckers.

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

[Kjella]

I have a problem with the paid support model 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.

I work mostly on custom code and we manage to do that all on our own without any financial incentive other than an never ending list of TODOs and deadlines. Ugly hacks with weird limitations that solve our immediate problem? Check. Solutions that are tweaked right up to the wire and never properly documented? Check. This is pretty much the default unless you start funneling money from service & support into tasks to make it more consistent and user friendly. I doubt anyone is consciously trying to write obfuscated code, though I've certainly duct taped things together that might give that impression.

Re: I have a problem with the paid support model

[Zehsi]

like libreoffice, blender or gimp.

Re:I have a problem with the paid support model

[Jastiv]

I think the paid support model is great and should be used more often. First of all, it does not rely on closing the source on any part of the program. Second of all, no matter how awesome the documentation is, how simple and step by step, someone is not going to spend all the time reading that. Thirdly support can also include software customization (more code, feature ads and bug fixes.) Lastly, companies do not have a reason to make it hard to use, because if its easy, they can just collect subscriptions and do not have to respond to help requests because the customer has already fixed the issue.

Re: I have a problem with the paid support model

[astrofurter]

Exactly. Everything Red touches gets harder to use and less stable. That's basically their business model.

Re:I have a problem with the paid support model

[Mandrel]

Yes, paid support does have the big advantage of leaving everything open. However, because support and customization is so expensive, only a small fraction of the users can afford it, with the rest left to fend for themselves, often with bad docs. Also, paid customizations can lead the software in the direction of the users with the deepest pockets, rather than in the direction of features that most users want. Yes, this is how capitalism works, but I think outcomes would be better if more users paid less.

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.

Reuse Old Code

[DatbeDank]

It's time we reuse old code. Backspacing incorrect code is unacceptable!

We must copy and move it even if it's only 1 character.

Every bit and byte is special and cannot he deleted!

Ironic because most coders just copy and paste code anyway!

Re:Reuse Old Code

[Dayze!Confused]

Life begins at the keystroke and deserves a chance to make it upstream. We aren't going to pay for keeping it upstream, and if it goes unmaintained and gets security holes we are't going to pay for that, we aren't socialists, but you can't simply git reset --hard HEAD^. It doesn't matter if it was a drunken night of keyboard tapping, it still has rights.

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."

Re:Translation

[saider]

If I only had mod points

"...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?

Re:"...we have to coordinate..."

[QuietLagoon]

...that successfully sells software....

FTFY:

that successfully sells buggy software.

Re: You know what open source software needs?

[coolsnowmen]

If you truely believed that, you would not have wasted either to write that.

New Microsoft employee in charge of GitHub asks...

[Narcocide]

Holy fuck, how are you guys paying for all this!?

(LOL)

Re:"proportionate incentive to contribute"

[Zehsi]

tru dat! just ask red hat, but wait they are busy laughing at you lol... or ask the github guys...

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.

Re:What's missing is money

[Mandrel]

I totally agree with your concept of just charging for open software — JFC. Even though it violates the FOSS's Freedom 0 (the freedom to run), such a licence can still retain the real advantage of Open Source: being able to inspect and tinker with it yourself, so you can fix bugs and release improvements.

Check out the DevWheels Licence. It's like your PML, but includes a way for licence payments to be distributed to developers of upstream and prerequisite packages, which allows someone forking and adding value to get a share of the revenue, rather than all of it going to the owners of the original package.

DevWheels doesn't have your idea of using a hash to validate licence purchases. That would be useful to determine eligibility for either upgrade pricing or support. As you say, it doesn't matter that this wouldn't stop people running the software without paying. Everything can be cracked, open stuff more-so . One must rely on moral pressure, and also having the software do some minimal checks for the presence of a licence receipt, so piracy needs to be a conscious act of bypassing this.

Re:What's missing is money

[sichbo]

Hey cool, cheers Mandrel. I like the spirit of DevWheels, thanks for the link. I think the execution might be a bit too wordy, with all the bullet points, caveats and instructions etc. I prefer simple things :)

For developers who build on top of other people's code rather than rolling their own from scratch all of the time, it makes sense that there should be a clear and obvious way for dependency authors to be paid as well. Perhaps a key aspect of a PML could be that licensing only applies to end-user products or server applications. If you're using another author's PML licensed work as part of your own PML library, what you'd do is basically nothing. The other author's code source files remain alongside yours. Downstream products using your library are obliged to pay the other author + you, so they should have two *.pml receipts in their source tree. Simples. Perhaps as a courtesy if components end up with a bunch of PML dependencies, the readme should list them in bullet point form so "consumer" developers don't have to go fishing through every file in the source tree. Or something like GitHub will have already scanned the source tree and have PMLs listed in the clear up front.

Where it all falls apart is when an upstream author drops off the face of the planet and companies can no longer get a license. There's a gap there for GitHub or some company to provide a simple and familiar licensing experience and collect licensing fees in trust. So the purchase link becomes something like: https://github.com/sichbo?pml=.... And there's a tidy little familiar form so you just tick what you need, pay the bill, and receive your *.pml file and get on with life. Maybe throw on a deadman's switch such that *.pmls are issued for $0 when the original author is no longer able to accept payment (destination bank account closed) and a payment transfer issue isn't resolved after 12 months or whatever.

Re:What's missing is money

[Mandrel]

Licensing would be the least work for both end-users and developers if GitHub ran an "Open Software App Store" that accepted pay-licence fees from end-users, and distributed these to developers, both those in the fork and prerequisite trees, and within the packages themselves (based on a registered developer income share). I responded to GitHub's request for suggestions with just this, pointing out that it could earn them, like Apple and Google, income via an app store cut.

The wordiness of the DevWheels licence just formalizes all this app store functionality, so licensing can still proceed if a store isn't available, plus making sure that no store has a monopoly. I think it's better to put the burden of licensing the dev-chain on the developers themselves, rather than requiring end-users to get multiple licences. But the presence of the automated licensing of an app store makes both approaches equivalent.

And yes, some of the detail of the DevWheels Licence is what to do when you can't pay someone in the chain. Again, an OSAS could handle this smoothly, but the licence needs to be clear about what happens when there's no app store. DevWheels chooses to have end-users get licences from the directly-upstream packages when they are unable to get a licence for a package they want to use, with any licence fee increment by this package forfeited, and have developers do the same thing of moving one level up the tree when they're unable to forward a payment.

Words

[AHuxley]

Backbone - People have to pay their ISP a lot more.
Tools - Tools for all the US intelligence community.
Dependencies - Captive market.
Coordinate - A SJW will have to approve your project.
Communication - any emerging crypto gets to the NSA and GCHQ every time.
Money - rental software.
Communities - looking at our brand while working.
Analytics - helping one side of politics.

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.

Is GitLab OK?

[tepples]

If you see the phrase send us a link to your GitHub project on a job posting you can be sure GitHub made a back room deal with the job poster

Have you asked these employers if they'll consider repositories on GitLab, Gitea on your VPS, or Gitea on your shared hosting?

Pay Me License is not OSI approvable

[tepples]

Pay Me License violates point 1 of OSI's Open Source Definition.

Re:Pay Me License is not OSI approvable

[sichbo]

That was genuinely interesting, cheers for the link. Having never had any inclination to look up a formal definition I've always just presumed that the spirit of open source licensing was that it remain openly accessible and modifiable and remain as such, not necessarily always free, as in beer. The end-products that rely on them sure as fuck aren't. I suppose what's needed to make things a little more economically sustainable for authors is a new class of "open" licensing that puts dollars in the programmer's pocket whilst still allowing the community at large to benefit from reading, modifying, learning from, security auditing or debugging the publicly visible code. Maybe one could call it Visible Source, VS for short. ;)

Re: "proportionate incentive to contribute"

[jpaine619]

Funny. I wouldnâ(TM)t use any open source software. It is literally really terrible software. Perhaps if they didnâ(TM)t try to force people to contribute they would have better software. I imagine if you were forced to contribute you would not be giving your best code to GitHub. So who would even want the code on GitHub? I wouldnâ(TM)t even give it a first look if I wanted sofware.

None of what you said is correct. You are an idiot. May I suggest you look up the BSD license?

By the way, asshole, if you're using Windows or Mac you're using Open Source components..

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.

Don't expect packaging help from the community

[tepples]

You can distribute your computer program under any license you want. That doesn't mean others have to put their resources toward helping you package your software for various distributions. And if your license doesn't meet FSF's four-point definition of free software or OSI's 10-point definition of open source software, you're not going to see nearly as many people willing to spend such resources.

Re:Don't expect packaging help from the community

[Mandrel]

If a licence made the software open (source-available and freely-forkable), but also allowed contributors (both in-package and to downstream forks) to get a share of pay-to-run revenue, I see this attracting developers at least as strongly as an OSI-approved licence.

Re:Don't expect packaging help from the community

[sichbo]

That's a fair point, a non-free license will repel devs willing to spend their time spreading your work. But I guess when an author's objective is to put food on the table 1000 distributions x $0 = $0, so exposure isn't really a factor for them. The only selling point I can think of regarding exposure through OSS is happenstance referrals/support work from some company that has a problem with it which they can't fix themselves or don't want to spend time on. Not exactly sustainable, and it punishes programmers who write their code correctly in the first place :)

Re:"proportionate incentive to contribute"

[NikeHerc]

Does that make him wrong?

A ms apologist would surely say nope. The rest of us won't necessarily agree.