Infrastructure to support organization accounts

Mostly sounds reasonable to me.

#1: Not sure the implementation matters all that much. If it was a separate role, we'd have to reshuffle all the d.o permissions so that auth is shared by all users and then separate roles for people vs. orgs with any perms that aren't shared. Based on what's been listed so far, perhaps a profile bit and some custom altering is easier, but I believe there are permissions for everything you're talking about restricting, so I think this could be done almost entirely without code.

#2: Again, not sure we need anything custom at all, other than perhaps a way for users to self-select if they should be in the org vs. person role. Pretty sure there are modules available that do this much.

#3: I agree we want to discourage abuse of org users, but I'm not sure that particular carrot is a good one. Do we really want to require orgs to also create themselves an org user just to have an org page? I have nothing better to suggest right now, just registering a concern. Even if we do this, nothing stops people from doing Bad Things(tm) with Git, so I think either way, we need to adopt a "ban troublemakers where we see them" attitude, and accept that there might be some unfortunate commits pushed into Git. That's always possible, and I'm not sure this is fundamentally more of a problem here than in any other possible case.

#4: Great idea, but sounds complicated. ;) We'd have to teach all the places that are trying to show your organization contributions to be date-aware, and that sounds like a bit of a rat's nest. But we absolutely need to start collecting this data if we're going to ever be able to do anything resembling smart. Ideally, we'd expose start/end dates to users (kind of like the employment and school fields on a linkedin profile) since although a reasonable default, I'm sure most of the time the actual dates are going to be different than when you finally remember to change your d.o profile.

Overall, tentative +1 to the proposal, with a few (minor) concerns about the best ways to implement it.

Thanks,
-Derek

#4 seems like a related issue, but not directly and doesn't feel to me like part of this. I don't really see it mentioned in #186349. Can we remove it from this?

#1, 2, 3 - do we really need a preventive solution for this? Why not a reactive solution?

Greg - are you saying that you would rather implement this as it is requested/needed, rather than allowing orgs to set themselves up this way proactively? Just clarifying.

re #3 - yes, exactly. In general: I feel like we shouldn't build things until we see clear evidence that they are needed. If we go for 1 year and somewhere along the way a single org account is used for commits then we would warn them/block them via the webmasters queue AND we could re-evaluate if it's worth any code to prevent problems. If it happens 20 times in the first month....ok...we need a preventive code solution.

Before looking at the implementation aspect, can all scenarios be discussed, to check the pros and cons:

Pros:

1. More contributions/contributors from organisations will encouraged.
2. More visibility of a contributors when they shift companies, which provides a fb timeline like data for evaluation purpose.

Cons:

• When original author of the company leaves, who will be allowed to take ownership of Organisation node, to be precise what will be criteria.
• Who bans the miscreants within organisations, a special role.

When original author of the company leaves, who will be allowed to take ownership of Organisation node, to be precise what will be criteria.
Who bans the miscreants within organisations, a special role.

1. the organization manages their account. If they (collectively) don't control the email associated with the account we have no responsibility to give it over to them. This is the same policy for any account. IMO this is fine: we are a tech community and tech companies can setup emails to forward.
2. Same as now: webmasters queue.

+1 to moving point #4 from here into a separate feature request. That's worth doing regardless of this issue. It's also hard and complicated, and if we pursue it as part of this, it's likely to slow this down or potentially derail the issue completely.

I think its more important initially to agree that there can't be organization-level commit bits than it is to code in constraints until we see abuse of the policy.

To be clear, what most concerned me in our BOD discussion of the topic was the trial assertion that it might be a good thing to assist some small shops in obscuring the identities of their individual employees through an aggregate commit bit controlled at the organization level...because otherwise their best employees get "poached" for higher salaries. I feel VERY strongly that we should never encourage intentions to undermine individual-level meritocracy by obscuring contributors. This is the primary engine of open source (that the individual earns merit for direct actions). If we can contrive a way for companies to get credit for funding development (or for employing developers with lots of merit) then that's an additional goodness, but we should absolutely avoid undermining the individual in so doing.

Under all circumstances, I want to avoid that we have a situation such as one that represented itself here:

http://www.h-online.com/open/news/item/Social-Media-Widget-for-WordPress...

ie somebody made fraudulent commits and it was impossible to verify who was the culprit since the account was possibly shared.

Since this is difficult to add after the fact, I believe I must insist on having code that blocks such things before they can happen.

Oh, and any director who believs that undermining meritocracy is a good thing should feel free to resign.

I think it'd be fairly easy to implement 1-2 right away, perhaps without any custom code at all, and that would prevent organization accounts from having direct commit access.

Of course, nothing stops a rogue shop from creating an account, claiming it's for an individual, bypassing this, and pushing commits. But that's true today, so I don't understand what's the big deal.

I think so long as the policy is obvious that we don't tolerate committing as an organization in any way, and we'll crack-down hard if we see it, we don't need to try (and ultimately fail) to *prevent* it.

At that point, why bother with carrot complications? I think 3 is perhaps won't fix.

Thanks,
-Derek

I guess I'm not being clear. Let me try again. I proposed implementing 1 and 2 via separate rolls, using the permissions that already exist to restrict all the things you're talking about restricting. The only possible custom code (and there's probably a module for that) is to let users select a role on account creation.

So, from the beginning, "organization" accounts cannot push to git.

I'm just saying we don't need to then try (and ultimately fail) to somehow prevent people from saying "yes, I'm a person" and then acting like a company. We just make it clear that won't be tolerated, and if you try that BS, we'll remove you and all your content (or whatever club we want to beat them with).

Sure, carrots can come later.

Hope that's clear.

Thanks,
-Derek

p.s. The "harm" to the original carrot as I see it is that we then *require* organizations to have an organization user if they want an organization node. I don't know we want to incentivize that behavior. If they're happy to do all their company business directly as the specific individual humans, why stop them from doing it that way? I think these accounts should be opt-in, not expected. The carrots are all the stuff in the summary before the numbered proposals. You want an org user because you want your org node to be owned by an account your company controls, not an individual. Fine. Create an org account for it. And that account can't do anything else. But let's not make everyone jump through this hoop if they don't want to.

p.p.s. And since I appear to be unclear today, let me reiterate from #1 that I'm not tied to separate roles as the specific implementation, although I suspect separate roles will ultimately be easier than custom code, since I'm pretty sure the main things we care about are all easily done via the existing perms.

I generally like the roles-based approach. For assigning roles to users on registration, I've found this:

http://drupal.org/project/autoassignrole

If I might suggest an alternative idea for implementation.

On sites like Livejournal, you can work as either your own user account, or a community account that you manage. But you're still always logged in as you, an individual user.

So what we could have here would be:

- organization user accounts, which you don't actually log in as, and are connected to normal user accounts which are their 'members'.
- org accounts can own project, organization, case study nodes
- a user who is a member of an organization can edit the nodes their organization owns -- but they still do so as themselves
- you create an organization while logged in as yourself, at which point you'd become its first member
- when creating nodes that can be owned by an org user, you get to choose whether you are working as 'yourself' or (one of your) organization users.

FWIW, I'm not opposed to #1, 2, 3 as long as whatever needs to be done is done quickly.

I have no strong preference on the implementation details, and defer to those who would actually be implementing this on that front.

At a high level, though, I like this plan and very much agree with Danese: Individuals and companies can both contribute to Drupal, but they do so in different ways and should be tracked as different things. We need to make it *very* clear that using one account type for the other type of activity is *not OK*, and that needs to be made clear up front before there are problems, not after. It's always harder to put the horse back in the barn.

So the MVP sounds like a second account type for Orgs that cannot use the "Git access" functionality so it can never commit code, but is somehow linked to who works there currently. That account page can also list whether or not that Org is a DA organizational member. (I think that's all of the "easy" data we already have available.)

Once that's in place, there's a lot of other things we could do with it in follow-ups, including:

- fancy schmancy organization nodes/pages (as discussed in the OP)
- Historical tracking of who worked where when
- Historical tracking of who contributed what while working somewhere
- Listing the conferences/camps an organization has sponsored
- Various other things designed to reward "good behavior" (by however we want to define good)

But those are all follow-ups and don't need to be in the initial release.

This gets into things for other issues. I'm just getting some thoughts out there.

Some projects, as in modules/themes/distros, have "sponsored by…" blurbs in their body text. It would be great to make that into fields, so we have structured data we can surface as contributions on organization pages in the marketplace. It could be a field collection containing an organization node reference and a text field to let the module owners describe the organization's level of involvement.

With the "Maintainers for …" block showing who is making commits, I'm not sure we even need the "Posted by …" line. We could do a better job of showing who helps maintain/triage issues in the future, too.

One disadvantage is it doesn't help with the "Some Individual left the company, but node.uid is her UID, so we cannot make updates to the maintainers list now" unless it's tied to users.

I see that as a mandatory feature for this or some other similar form of access control.

I don't think the landgrab issue will be a big deal. Let's not solve it until it becomes one.

> but rather just add like new node reference fields (for organization nodes) on these elements (projects, case studies, organization nodes) that identify them as being owned by an organization.

Isn't that OG-lite?

#organization-contributions:

How is the case managed if people change companies or come from different companies - do their projects follow them to the new company? What about their spare-time pet projects? When are projects "their" projects anyway? If they are maintainers? Or co-maintainers? What if they contributed large amount of work without having that status? Or they have the status still while being away from the project for the last three major Drupal versions? What about serious funds dedicated to projects by companies?

Did the DA think about those effects in their plans yet?

Perhaps it makes sense to control this contributions-of-an-organization-listing by having (co)maintainers associate projects to 0-n organization nodes? This would als be a strong incentive for companies to dedicate funds, patches or employee time to contributions, even if the main maintainer works for a different company.
So rather than "Having a project node owned by an organization" as stated in the body above, the project node should be _associated_ with 0-n organzation node(s).

This could be transferred to non-code contributions like events, codesprints, usergroup involvement, too, by having an additional "contribution" node type, also associable with 0-n organization nodes.

Maybe via a "contribution" node type, also associable with 0-n organization nodes?

And furthermore, regarding project nodes, who's to decide what project is "owned" by what company? That's also unclear in the above draft.
Suggestions: The project's (co)maintainers jointly and unanimously decide about which project nodes are _associated_ (rather than owned!) to which organizations nodes.

And furthermore, regarding project nodes, who's to decide what project is "owned" by what company?

I think the answer to this question answers a lot of your questions: the project maintainers have to decide this for themselves.

@danielnolde: Also, many of your questions are being considered at #1968480: Keep historical tracking of users' employers which was specifically removed from the scope of this issue so that this doesn't become an unworkable mess. Please contribute there if you have anything new to add.

Thanks,
-Derek

I agree with *most* of this.

BUT... personally, I don't think organisations should be allowed to "own" projects at all. I see no need for that. And I say this as then owner of an organisation that routinely has developers produce and open source code. We *always* encourage our developers and contractors to PERSONALLY share code they write for us and, in turn, they usually put a nice hat tip to us on the project page, for example:

http://drupal.org/project/doorman <- Marcus doesn't work for us, he was on a contract, he still maintains Doorman, we have no desire to wrap our arms around that module and make it 'ours' ... otherwise, why would we put it on d.o in the first instance?

http://drupal.org/project/qualtrics <- Vincenzo left us over a year ago, but he is happy to acknowledge us as funding the module and continues to maintain it, we do not, and if we did I'm sure Vincenzo would add one of our current devs as a committer.

I think organisations should be encouraged to behave like this, encourage individuals to contribute their work and (optionally) hat tip their employer. I've read the argument for organisation-controlled projects and I think it's flawed. It can flip either way.

If the code is going on d.o anyway, it is FOSS by definition, if the developer leaves the project and refuses to collaborate with the organisation they left (which, I might add, has *never* happened to us) you can fork it. Seems to me there's a far higher risk (and historical precedent, see Ubercart debacle that forced Ryan out) that an organisation will hold on to a project and hinder its development by refusing to allow a developer to continue to collaborate when they leave.

We already have an organization node-type on drupal.org, and I feel that's enough.

Github's hierarchy of organisation and individual accounts addresses requirements such as privacy of content and delegation of privileges. Organizational project ownership makes sense in Github's world of (potentially) proprietary code, but in open-source, I believe individuals should manage projects.

I especially believe individuals should be given recognition for their contributions - whether that's commits, documentation edits, application-reviews, or anything else.

If this is to 'credit' organisations for the support they give to the community, then we already have the tools to do so - project descriptions, for example. I also wouldn't necessarily wouldn't want *all* my work to be credited to my employer - for example, if I make a documentation edit on a weekend, on my own computer.

If we come up with a technical solution to associate commits with an organisation, and so give an organisation credit for work they've sponsored, I think that'd be OK - but I also think that's going to have some challenging technical engineering which doesn't fit very neatly with git's technical architecture, so the UX, DX, or maintainability might suffer as a result. I do feel that as a project maintainer, we've already got a way to recognise the contribution organizations make towards Drupal, and that's through a straight-forward credit in the project description.

I think both greg.harvey and manarth make some good points. That's certainly a good model for contributing, and great if you (and others) want to continue doing it that way. That's part of why I (more and more strongly) oppose the idea that we should at all *encourage* the creation of organization users (and absolutely would try to veto (such that I can) the idea that they should be *required* for doing anything).

But...

Those are not the only models. Sometimes, a company really does invest in the creation of some modules (or themes -- e.g. Fusion and TNT), and that code is really central to the company, and they want to ensure that their company continues to have access to managing the project node, even if individual developers move on. I agree it seems far-fetched that this would actually be a problem (e.g. project node owner X leaves company Y and refuses to give access to new developer Z), but a) that can happen just as easily with/without organization users and b) if there's a reasonably good solution that doesn't require volunteer d.o webmasters to have to get involved and try to sort it out, great.

Dysfunctional relationships between maintainers, whether they be organizations or individuals, are always possible. The idea this could be solved if only we could force everyone to retain/have commit access is, I'm sorry if this is harsh, laughable. If the maintainers can't agree on the direction of the code, someone needs to fork it or walk away. Preventing a level of indirection on controlling the maintainer tab isn't going to help this.

That said, keep in mind that NO ONE in this thread wants organization users to actually be able to commit code. All commits should happen by individual users, not organization users.

Furthermore, any talk of trying to aggregate contributions from individuals into an organization is misplaced in this thread. A) that really only makes sense to do on the organization nodes, not organization users and B) it's a much harder problem. So let's please drop that from the scope and this discussion. If you're interested in that, the places to talk about it are:

#1968480: Keep historical tracking of users' employers
#1969220: Explore ways of incentivizing contributions from organizations

This thread should only be about allowing organization users to:
0) exist and
1) own (certain) node types.

This should happen for only two reasons:
1.a) To give the organization a level of indirection for access control on further edits to those nodes (the main problem).
1.b) To give the organization another little place for "advertising" (very minor, and we have other ways, but I don't see the harm in letting it happen).

To me, everything else is either a bad idea, or out of scope from this issue. ;)

Thanks,
-Derek

dww++

If the maintainers can't agree on the direction of the code, someone needs to fork it or walk away.

Very good point. ^^

I believe the possibility for organizations to have accounts, with mentioned limitations, would make a great improvement to the community. Like many commenters I don't see this as an either or, that organizations has to have accounts. It should be an option for them to use if it suites them. As @greg.harvey points out in #32, its a model that doesn't really suite the needs of his organization.

I also agree fully with @dww's points in #34. Companies sometimes needs control of their contributed projects as they might be central in their business and represents a big investment. Then being able to control the project node will likely be important. The disagreement risks he lists are in my opinion already existing. My belief is that this change could actually help prevent those from happening far more than it will create new ones as a result of them.

It looks to me that this, and related, issues has gone a bit stale the last two months. However reading through I clearly get the impression this is going to happen in one form or another.

Would it then be "safe to assume" that any organization accounts, similar to the @whitehouse account, can be created now to be used for creating project nodes, is "OK"?

#1968480: Keep historical tracking of users' employers

@tsvenson my sense is that yes, this issue has gone somewhat stale as has #1863498: Create Basis for ToS to allow organizations to share accounts. However, that kind of doesn't matter.

1. We don't actually have a Terms of Use for registration of accounts (if you think we do, point me to it because I'd love to see it). All we have is some instructions on the registration page and a body of webmasters who will block accounts that misbehave. We have a more official agreement to commit code
2. Those webmasters (self included) are allowing organization nodes as long as they follow the guidelines in #1863498: Create Basis for ToS to allow organizations to share accounts. In my opinion, the fact that we haven't had a lawyer turn those guidelines into a real TOS and that we haven't spent the code to implement the digital enforcement of those rules is a footnote on an otherwise accepted policy.

As I was thinking about this I realized that our current git policy is a bit incomplete. Filed #2043147: Add "as an individual" to the git access agreement to fix that.

@greggles: Thanks for a quick reply about that it is OK to create organization accounts and use them with the limits discussed here and in related issues.

I agree that the lack of a proper ToU is a concern. Having one that covers this and an updated ToS to complement would be a good thing. Particularly when looking at the size of our community and the Drupal ecosystem as a whole.

Looking at things, I believe we have an excellent opportunity to address this in combination with the upcoming upgrade of *.d.o to Drupal 7. When that upgrade goes live users will direct their focus on exploring the improvements and (hunch) be motivated to also spend some time tuning up their own profile too. Thus it would be a perfect opportunity for an official introduction of the organization accounts.

However, the migration to D7 is not that far away so there isn't that much time to come to consensus about this. How can we get this moving again you think? One idea could be that Holly, or someone else within the DA, writes a blog post presenting this proposed change. That would bring it to the attention to more within the community and we would quickly get feedback on it from both individual users and organizations.

One aspect of organizations owning/controlling the project node that shouldn't be underestimated is the extra motivation it will have on maintaining those projects. After all, they will put their brand name in direct relation to it and that is quite different from a sponsor blurb in the content part of the project page. Since it becoming more and more common that clients are looking at the community involvement before they hire a company, then those projects will play a role here I believe.

I also believe it will make it easier for a shop to give compelling reasons about the benefits of hosting code developed on d.o as the control of maintaining that specific code will remain with the shop etc.

Likewise I believe this change will motivate more shops to be more active in contributing to d.o as they see that they can easier use their contributions in their own marketing and sales processes.

The risks mentioned that some organizations might misunderstand how open source works and are to stiff with the control I don't see as a problem. Sure, it is going to happen, but then nothing prevents anyone from just forking the code if no other solution is possible. Yes it will be a momentary hiccup, but nothing more.

As far as I understand, the D7 upgrade feature list is set ... the idea is to finish the migration (with the current migration feature set) and then start tackling further changes and feature requests once the migration itself is out of the way. The only reason an enhancement such as the 'related issues' blocks will be making it into the migration is because a volunteer not involved in the official migration work stepped up and coded it themselves. So while I won't go so far as to say it definitely won't happen during the migration if there is any coding involved, I'm almost certain that the only way you'll see it is if someone not currently involved in the D7 upgrade does the work ... and even if that happens, it's probably more of a fast-follower than something to be included in the migration itself.

x

I think there is more activity on adding Organizational accounts than would be suggested by the last post.

Adding a related link.

While we are not quite ready to deal with a new role/type of account for organizations, we have a way forward that the tech team is going to implement over the next few weeks.

One of the big requests in this thread was allowing maintainers to give credit to organizations that helped sponsor or support code development. GitHub handled this by allowing its users to create an organization and associate code to that organization. We can match this model without creating a new type of user.

In issue https://drupal.org/node/2267789, we are going forward with a change that will add an entity reference field on projects that can reference organizations as "supporters". When maintainers add this reference to a project, it will show up on the project page. Also, the reverse reference will show up on the organization page. This will allow interlinking and solve one of the big asks in the original request.

Maintainers will still have the responsibility to add the supporting organizations.

We'll come back around to the requests for organization accounts in translation as a separate project.

One of the things that is confusing out of the new TOS and organization pages is that organizations have the ability to create project nodes. However it seems like to create a module, you have to commit the initial code to git. Which organizations can't do, at least until they've received approval for their first project. Which they can't do because they can't commit to git. Am I misunderstanding how this is currently implemented?

So what we have instead is an individual who didn't write the code (we've been sitting on several modules that we wanted to contribute but haven't due to figuring out the internal process) who now has ownership for modules the company uses. This seems like the worst of both worlds to me as the objection to organizational users was to prevent a company for getting credit for code a developer wrote. Now a different developer is just getting credit instead of the person who actually wrote it. And regardless of what the community says, in our company we have a change management process where we don't allow staff to be the project owners for modules for the reasons listed above, ie what if a developer leaves.

From an actual use case perspective, here are the issues:
1. How to get an organization able to create a project without commiting code?
2. How to get the initial code commit into the project? One use case may be to let the organization create the project and then add maintainers to it for the initial code commit.
3. How to allow maintainers for an organizational "owned" module to be eligible for review bonuses on projects. In our case we have a team time scheduled to work on patches next week, we could just as easily get 10 devs in a room and help review modules - seems like a win-win.

From our perspective, we *want* our developers to get credit for the code they write. So in spirit we are totally on board with them doing commits. I also believe the view that companies will be more motivated to maintain code with their brand on it is also true, which seems like it would benefit the community as those companies will be more likely to commit time and funds to updating stuff.

Thanks @webchick :)

@crimsondryad As @webchick mention, having an organisational account creating the project node changes little about who will be able to commit.

However, it does add some interesting and, in my view, beneficial new potential uses. Organizations that own the project node will not only be able to better protect important contrib projects they have initiated and, in most cases, also relies on in they own business and/or clients, it also gives them a larger responsibility so that their projects are maintained as good as possible. After all, they will put their own name behind such projects in a way just sponsoring doesn't measure up to.

I think this is a great way to give organisations even better ways to contribute to the Drupal project, while at the same time also be able better manage their valuable investments.

Done right this should actually make Drupal even more attractive, especially for new users as this shows that an organisation is willing to put their own name behind, thus take a more visible responsibility for the future maintenance and development of such projects.

After months of working out the language, organization accounts are now officially supported in our terms of service:

3. If you are sharing your user account with multiple people (e.g. as your “official” organization account), you are not allowed to do the following using this account:

• commit code to Git repositories on the Website
• create any nodes except for organization, case study or project nodes
• comment on nodes

If you are sharing your user account with multiple people you ARE allowed to:

• create project nodes
• create organization nodes
• create case study nodes
• submit translations to localize.drupal.org

I'm closing out this issue as fixed, but we are open to further feedback as this goes into general usage. See also Issue #1863498

This issue is about adding specific features to the site and I don't think all of the features were added (I'm not sure there was agreement we should do them, but there wasn't agreement we shouldn't).

So, I think the policy is in place which is great, but this issue should either be left open until the work is done or we should agree that the remaining tasks are not going to happen.

@greggles, that's fair. I can change the status to postponed if that would be more appropriate to get additional feedback.

Until we see how much uptake organization accounts have, I'm not sure how much work is warranted. Perhaps we could check back on this issue in 6 months—or sooner if we see abuse of organization accounts.

OK. I don't think any "additional info" is needed from the reporters. So just postponed.

https://www.drupal.org/u/internetdevels is clearly an organizational account. Should it be fair for such an account to post patches and rise so high on http://drupalcores.com? Think if Acquia or Chapter 3 did something like that... The data would become useless.

I think @alexpott talked to InternetDevels Feb 3 2014 about not posting patches (anymore) from an org account.

I thought there might have been an issue documenting that, but I cannot find one.

IMO, if an organization posts comments or patches their account should be blocked temporarily as a warning.

InternetDevels hasn't commented on an actual core issue in over a year. However they continue to get commit credit because the issues they contributed to are only now being committed. I don't think there is a current/ongoing problem with that account.
For example:
Commented #2091431-10: Update hook_help for Update Manager module on Jan 23 2014
Committed #2091431-30: Update hook_help for Update Manager module on Apr 17 2015

@webchick then we are in agreement ;) Because #51 points out that they were already warned.

It does appear that tim's analysis is right - current credit is being given for old work. There's only been one comment under that account since June of 2014:

mysql> select from_unixtime(created), nid, cid from comment where uid = 211684 order by created desc limit 5;
+------------------------+---------+---------+
| from_unixtime(created) | nid     | cid     |
+------------------------+---------+---------+
| 2015-04-28 10:26:39    | 2423505 | 9871887 |
| 2014-06-16 07:25:28    | 2253671 | 8883995 |
| 2014-06-02 10:11:28    | 2253671 | 8835591 |
| 2014-06-02 10:04:01    | 2253671 | 8835573 |
| 2014-05-09 09:45:36    | 2262713 | 8763425 |
+------------------------+---------+---------+

I guess that was a mistake and there's no patch on it anyway.

3. To discourage organizations from skirting around the permission lock-down by not checking the "Organization" box in their profile, add a "carrot". One idea is making it so "Organization" nodes can only be owned by users in the "Organization" role (we'd need a transition period to sort this out), and at the same time adding more "oomph" to those pages; for example, an auto-generated list of recent contributions by their employees, etc.

We’ll need a different carrot now. I’m not sure I can think of one, other than more-“cleanly” allowing multiple people to own/manage an organization account. I wouldn’t want to put anything in which requires using an organization account for organization pages; it is perfectly fine for an individual to own the page.

1. A flag on user accounts to identify them as individuals vs. organizations. This could be implemented in a myriad of ways; for example, a user role (although Drupal's permission system makes this a bit dicey since there's no way to remove permissions from a role), or a Profile module field. In any case, it's a checkbox that's exposed on the registration form and on the user profile edit form.

I think the best way to implement this today is a regular field on user accounts. Roles could work with a bit of customization, which we don't need, and all implementations are going to be removing access in alter hooks, etc.

User accounts now have a “Is this a shared account?” checkbox; we now have a way for organizations to identify themselves.

An "organization" user only gets permissions to post organization nodes, case studies, and projects only. All other permissions (commenting, posting forum/issues, and especially the "Git access" checkbox on the user profile) are removed.

Most of these restrictions are being deployed, the restrictions on creating nodes and agreeing for Git access. The remaining restriction needed is on commenting.

I believe this can be called fixed now. In addition to the previous changes, accounts marked as organizations can now no longer post comments.