GitHub Seeks Feedback on 'Open Source Sustainability' (github.blog) 87
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."
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."
Three Step Process (Score:2, Insightful)
1. Embrace
2. Extend
3. Extinguish
Wait, what was the question again?
Re: (Score:1)
Why, you don't mean that Microsoft would steal all of those ideas, do you? You mean, after buying GitHub, they want everyone's secret sauces because they believe the FOSS communities don't know WTF they're doing?
Oh.
Beware the bait, my friends. Once they sink the hook, you're in a boat to a market.
Microsoft needs your feedback/help (Score:2)
Re: You know what open source software needs? (Score:2)
Re: (Score:1)
I have a problem with the paid support model (Score:5, Interesting)
It also would tend to encourage crap / no / minimal documentation.
So some alternative to that model would be helpful.
Re: (Score:3, Informative)
Re: (Score:2)
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
Re: (Score:1)
Re: (Score:2)
Re: I have a problem with the paid support model (Score:2)
Exactly. Everything Red touches gets harder to use and less stable. That's basically their business model.
Re: (Score:2)
Is GitLab OK? (Score:2)
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 [webfaction.com]?
Re: (Score:2)
A ms apologist would surely say nope. The rest of us won't necessarily agree.
Re: (Score:1)
Young Whipper Snapper (Score:2, Insightful)
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 quic
Reuse Old Code (Score:2)
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: (Score:2)
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 (Score:5, Funny)
"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: (Score:2)
If I only had mod points
"...we have to coordinate..." (Score:4, Funny)
Re: (Score:2)
...that successfully sells software....
FTFY:
that successfully sells buggy software.
New Microsoft employee in charge of GitHub asks... (Score:1)
Holy fuck, how are you guys paying for all this!?
(LOL)
What's missing is money (Score:2)
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: mailt
Pay Me License is not OSI approvable (Score:2)
Pay Me License violates point 1 of OSI's Open Source Definition [opensource.org].
Don't expect packaging help from the community (Score:2)
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: (Score:2)
Re: (Score:1)
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 programm
Re: (Score:1)
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 programme
Re: (Score:2)
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 [devwheels.com]. 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
Re: (Score:1)
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 produ
Re: (Score:2)
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
Words (Score:2)
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 (Score:3)
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 (Score:3)
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.